I've seen various postings on the lkml on the issue of fsync()ing block
devices and the expected behavior. Some claim that fsync()ing the mount
point of a block device will flush its buffers, a HOWTO I read claims
that one has to apply it to the device node, because it is the
representation of the block device.
The POSIX standard demands [1]:
"The fsync() function shall request that all data for the open file
descriptor named by fildes is to be transferred to the storage device
associated with the file described by fildes."
To my interpretation this means that all buffers of a mass storage
device should be flushed when calling fsync() on its file
representation, i.e. /dev/foo.
I've tried various Ubuntu-packaged kernel releases (2.6.12 and later),
and none of it seems to actually assert that the data is written when
using code like
int fd = open ("/dev/sdb1", O_RDONLY); /* I also tried O_WRONLY */
or
int fd = open ("/media/usbdisk", O_DIRECTORY | O_RDONLY);
and then doing
fsync (fd);
close (fd);
Unfortunately, none of the code really blocked until the whole buffer
was written, and a diode on the mass storage indicated that data was
still being written to it after my testing application terminated, while
for a simple sync() call (or "sync" program invocation) the whole
process really blocked until the data was on disk, as proven by the
non-flashing diode.
I haven't investigated the code in detail, but fs/buffer.c suggests that
sync_inodes is invoked on sync() but not on fsync(), and the latter does
not lookup the block device the file refers to, thus not ensuring that
fsync_bdev() is called on it.
If you wonder why this is needed - over at GNOME we're having issues
where USB sticks are unmounted and the users have no clue when it's
ready to be removed [1]. We'd like to fsync() in a thread and tell the
users that an unmount operation is going on and still needs some time.
Because there may be multiple storage device attached, it isn't a good
idea to sync() all devices, but just that one which is about to be
ejected.
[1] http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html
[2] http://bugzilla.gnome.org/show_bug.cgi?id=329098
--
Christian Neumair <[email protected]>
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: Using fsync() to synchronize a USB mass storage device failed
- From: Andrew Morton <[email protected]>
- Re: Using fsync() to synchronize a USB mass storage device failed
- Prev by Date: Re: ata1: command 0x35 timeout sata_nv driver
- Next by Date: [PATCH] mm: Implement Swap Prefetching v24
- Previous by thread: ata1: command 0x35 timeout sata_nv driver
- Next by thread: Re: Using fsync() to synchronize a USB mass storage device failed
- Index(es):
 |