Comments on: ioctl, fsync - how to flush block device buffers?

By: Anonymous Coward

Anonymous Coward — Tue, 30 Nov 1999 00:00:00 +0000

Your problem with fsync is the interpretation of “all data for the open file descriptor”.

For every inode in use on the system, Linux creates a separate “page cache”. Fsync just writes the modified parts of this cache to the disk.

Different inodes have different page caches. So, an fsync on /dev/foo will not have any effect on the cache of /mnt/file, even though /dev/foo is mounted on /mnt .

I don’t think there’s a portable way to sync a specific filesystem (I don’t even know if there’s a good solution on Linux). AFAIR, sync(2) is not required to wait until all the writes have completed.

By: Stephane Chauveau

Stephane Chauveau — Tue, 30 Nov 1999 00:00:00 +0000

What will happen if you try to remount the device? I would not be surprised if the remount was delayed until everything is properly flushed. If so, the proper unmounting procedure could be: umount , mount read-only , umount

By: Diego

Diego — Tue, 30 Nov 1999 00:00:00 +0000

AFAIK “umount /foo/bar” syncs things before returning. I think it’d be weird to keep data in the kernel (be it caches or dirty data or anything) for a filesystem that is _not_ mounted.

But you probably should send this question to linux-kernel@vger.kernel.org (no subscription needed)

By: Christian Neumair

Christian Neumair — Tue, 30 Nov 1999 00:00:00 +0000

> AFAIK “umount /foo/bar” syncs things before returning

no, it doesn’t. eject does, though, it uses extra ioctl calls.

> I think it’d be weird to keep data in the kernel (be it caches or dirty data or anything) for a filesystem that is _not_ mounted.

The file system is still mounted when I invoke one of the syscalls, it is done before the actual unmount.

By: Rudd-O

Rudd-O — Tue, 30 Nov 1999 00:00:00 +0000

Please read my proposed solution at:

http://rudd-o.com/archives/2006/02/13/fsync-on-unmount-solution/