again: fsync does not work as we expect on 2.6

again: fsync does not work as we expect on 2.6

Post by Michael Uhlenber » Wed, 13 Oct 1999 04:00:00



Again, we write a couple of files to UFS, doing an fsync for each.
When we simulate a crash by drawing the plug, we find that
after reboot all newer files, say the last 30 or so, have
been moved to lost+found, admittedly with
correct content. This is however of no real use for us,
because we cannot tell, which file in
lost+found is which. This behaviour is specific to 2.6 only.
In 2.5 it  worked okay, in 2.7 it works if we mount with
mount option "logging". On AIX and HP-UX it also
works fine, in all OS releases of the last years.
On NT we use _commit() instead of fsync(), and it works fine.

By doing an fsync, we expect the file to be on
disk, complete with data blocks, inode AND
directory entry. True, the man page on fsync does
not explicitly mention the directory entry, but no
man page of any Unix (as far as I know) does, and
still it works as expected on most of them.
What good is it to have the data on disk
somewhere, but the filename has gone?

At first we supposed we were just overlooking
something trivial like a configuration option, or like the
"logging" option on 2.7. But now apparently this
behaviour can not be changed, and only we consider
it a bug? No one else has the need to be
absolutely sure at some point in time that a new file
is truly written to disk AND accessible?

M.Uhlenberg, iXOS AG

 
 
 

again: fsync does not work as we expect on 2.6

Post by Richard L. Hamilt » Wed, 13 Oct 1999 04:00:00


Have you tried opening the containing directory read-only,
and doing an fsync() on it, as a workaround?



Quote:> Again, we write a couple of files to UFS, doing an fsync for each.
> When we simulate a crash by drawing the plug, we find that
> after reboot all newer files, say the last 30 or so, have
> been moved to lost+found, admittedly with
> correct content. This is however of no real use for us,
> because we cannot tell, which file in
> lost+found is which. This behaviour is specific to 2.6 only.
> In 2.5 it  worked okay, in 2.7 it works if we mount with
> mount option "logging". On AIX and HP-UX it also
> works fine, in all OS releases of the last years.
> On NT we use _commit() instead of fsync(), and it works fine.

> By doing an fsync, we expect the file to be on
> disk, complete with data blocks, inode AND
> directory entry. True, the man page on fsync does
> not explicitly mention the directory entry, but no
> man page of any Unix (as far as I know) does, and
> still it works as expected on most of them.
> What good is it to have the data on disk
> somewhere, but the filename has gone?

> At first we supposed we were just overlooking
> something trivial like a configuration option, or like the
> "logging" option on 2.7. But now apparently this
> behaviour can not be changed, and only we consider
> it a bug? No one else has the need to be
> absolutely sure at some point in time that a new file
> is truly written to disk AND accessible?

> M.Uhlenberg, iXOS AG

--
ftp> get |fortune
377 I/O error: smart remark generator failed

Bogonics: the primary language inside the Beltway



 
 
 

again: fsync does not work as we expect on 2.6

Post by Ben Olaso » Wed, 13 Oct 1999 04:00:00




>> ld: fatal: file values-Xa.o: cannot open file: No such file or directory

> Install Sun package SUNWarc (SUNWarcx for 64-bit Solaris)
> from your Solaris distribution.

Does anyone know which Solaris CD the SUNWarc package is on?  I've looked
through a few, starting with the Solaris 2.6 Software CD, and haven't found
it yet.  According to the Solaris FAQ, the packages a C compiler needs for
libraries & headers are:
SUNWhea, SUNWarc, SUNWlibm, SUNWlibms, SUNWdfbh, SUNWcg6h, SUNWxwinc,
SUNWolinc and SUNWxglh.  I found SUNWhea on the
Solaris 2.6 Software CD - it would be great to find the rest.

Thanks!

Ben

 
 
 

again: fsync does not work as we expect on 2.6

Post by Philip Bro » Wed, 13 Oct 1999 04:00:00



>...
>At first we supposed we were just overlooking
>something trivial like a configuration option, or like the
>"logging" option on 2.7. But now apparently this
>behaviour can not be changed, and only we consider
>it a bug?

there is a patch against S7, for fsck, I believe. perhaps there is a related
patch for your issue.

Also try the jumbo kernel/fs patch(es)

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

 
 
 

again: fsync does not work as we expect on 2.6

Post by Phil Edwar » Thu, 14 Oct 1999 04:00:00




+ >
+ >> ld: fatal: file values-Xa.o: cannot open file: No such file or directory
+ >
+ > Install Sun package SUNWarc (SUNWarcx for 64-bit Solaris)
+ > from your Solaris distribution.
+
+ Does anyone know which Solaris CD the SUNWarc package is on?  I've looked
+ through a few, starting with the Solaris 2.6 Software CD, and haven't found
+ it yet.  According to the Solaris FAQ, the packages a C compiler needs for
+ libraries & headers are:
+ SUNWhea, SUNWarc, SUNWlibm, SUNWlibms, SUNWdfbh, SUNWcg6h, SUNWxwinc,
+ SUNWolinc and SUNWxglh.  I found SUNWhea on the
+ Solaris 2.6 Software CD - it would be great to find the rest.

Ummmm....

+ > Install Sun package SUNWarc (SUNWarcx for 64-bit Solaris)
                                              ^^^^^^^^^^^^^^

Solaris 2.6 isn't 64-bit.  Only Solaris 7 and later is 64-bit.

Luck++;
Phil

 
 
 

again: fsync does not work as we expect on 2.6

Post by Michael Uhlenber » Thu, 28 Oct 1999 04:00:00


We now do the following:

String parent = "/something":
String file = parent + "/else";

int f = creat(file, ...);
#ifdef SOLARIS // workaround for fsync problem
int p = open(parent, 0);
fsync(p);
close(p);
#endif

... writing to f ....

fsync(f);
close(f);

The same for mkdir, so we fsync the parent directories
immediately after we create a new entry in them, when
we still have the pathname. When we call fsync/close,
the filename is often no longer known, and we do not
want to change the code, so that the filedescriptor
AND the pathname are passed as arguments everywhere.

The code is neatly surrounded with "#ifdef SOLARIS",
because on other OSs this is not necessary ;-(
Michael

 
 
 

again: fsync does not work as we expect on 2.6

Post by Casper H.S. Dik - Network Security Engine » Thu, 28 Oct 1999 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>The code is neatly surrounded with "#ifdef SOLARIS",
>because on other OSs this is not necessary ;-(

That it happens is a bug in the OS.  It shouldn' thappen.

Could you send a program and instructions on how to use it that
reproduces tis problem?  (As well as the OS release and mount
options used)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

again: fsync does not work as we expect on 2.6

Post by Andrew Gabri » Thu, 28 Oct 1999 04:00:00




>[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>>The code is neatly surrounded with "#ifdef SOLARIS",
>>because on other OSs this is not necessary ;-(

>That it happens is a bug in the OS.  It shouldn' thappen.

>Could you send a program and instructions on how to use it that
>reproduces tis problem?  (As well as the OS release and mount
>options used)

Casper, there's another thread detailing this problem, which
starts with the following article (and to which I contributed
a couple of articles)...


Newsgroups: comp.unix.solaris
Subject: fsync doesn't work
Date: Mon, 11 Oct 1999 09:33:30 +0200

Hi Experts,
we just discovered, that fsync() on our Solaris2.6/2.7 machines has
apparently
become a no-op.
We have a test program, that creates a lot of files, doing an fsync
immediately
before the close. When we run it on 2.5, and draw the power plug, all
the files
except may be the last one are there, as expected. On 2.6 and 2.7, most
of the
files end up in the lost+found directory.
Any ideas, or suggestions where to look?

Thanks a lot!

Heiko

--
Andrew Gabriel
Consultant Software Engineer

 
 
 

again: fsync does not work as we expect on 2.6

Post by Casper H.S. Dik - Network Security Engine » Fri, 29 Oct 1999 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>Casper, there's another thread detailing this problem, which
>starts with the following article (and to which I contributed
>a couple of articles)...

I know (and I did contribute too, but apparently all my Oct 6-20 articles
got black holed somehow).  I just like to have some code.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

1. fsync() in linux does not work???

I am creating an application (in C) than needs to write in synchronous mode
to a file. I tried with:
    fsync()
    open the file in O_SYNC mode
    open and close the file

Nothing works. The changes are not put to disk when I want to. Linux decides
when to write the changes to disk and that does not meet the requirements
for this application.

Has anybody an idea how to be done?

--

/Jiannis
***Reality is what refuses to disappear when
***you stop believing in it

2. Problems getting HSP56 MicroModem to work with SuSE 7.2

3. help on asynchronous I/O

4. cron not doing initgroups() in Solaris 2.6?

5. IDS on OpenBSD

6. I don t understand the eand if file unexepected expecting done, done is ?

7. Media Vision Fusion CD system supp???

8. courier-imap/maildrop now doing proper fsync'ing

9. queuing pkts using nf_queue_handler in bridge (PF_BRIDGE) mode not working in 2.6 kernel

10. mmap64() not working on Solaris 2.6.

11. 8139-based Airlink ASOHORL PCI network card not working under 2.6?

12. URGENT HELP: passwd -d not working ons solaris 2.6 anymore ?