Difference between "blockdev --flushbufs" and "sync" on Linux?

Question

Is there a difference in practice between running blockdev --flushbufs and sync(1) on Linux? (apart from blockdev flushing for a specific device, and sync being system-wide).

sync(1) manpage says it flushes file system buffers (only?). If do I/O to a drive (with say, dd) without going through a file-system layer, is sync really ineffectual?

When should I use one instead of the other?

Answer 1

If do I/O to a drive (with say, dd) without going through a file-system layer, is sync really inefficient?

This begs the question that writing to a device node bypasses "the file-system layer". I suppose in a sense it obviously does...

In any case, it doesn't matter. If what you are doing does not involve caching, then running sync (or some equivalent) anyway wouldn't be "inefficient": if there's nothing to sync, it's a trivial call.

When should one use one instead of the other?

I guess when you want to target a particular partition, blockdev makes sense. I can't see how it would have any particular advantage over sync otherwise (and vice versa).

Answer 2

blockdev --flushbufs, if implemented by the underlying driver/hardware, will flush write buffers on the device itself. In entreprise hardware block devices usually do not keep dirty write buffers unless backed up by a battery, where it could still be desired to flush them before moving the hardware or replacing the battery (this is usually done automatically at the end of the shutdown process, just before performing an ACPI shutdown or reset).

Most entreprise and higher-end desktop mechanical drives have a read/write cache that can be configured to do write caching or not, and this is the cache that would be flushed with this ioctl. It could be useful to ensure all data is flushed before unplugging an USB or eSATA-attached block device, even after sync has been performed.

This ioctl is not always reliable, some drivers or devices could be lacking an implementation or intercepting calls. IIRC even older versions of LVM used to intercept this ioctl when used on logical volumes and fail to flush the physical devices.

sync()/syncfs()/fsync()/fdatasync() have a different purpose, they will sync all unwritten data/metadata back to the device. That data may include dirty mmap()'ed pages, dirty buffers in the VFS layer and uncommitted filesystem changes. fdadasync() flushes only the data for a specific file so it's the most efficient way of making sure data changes have been flushed (it may still delay some metadata updates unless required, such as file size changes). All other sync() calls will flush everything on a file, filesystem or all filesystems. It should be the program's job to sync their data if it's deemed important, and if you have to resort to a full sync call to ensure everything is properly written it's obviously much less efficient (the sync program can also sync a specific filesystems or file's data, see man sync).

If the goal is removing a device and you can unmount it, you don't even have to sync; unmounting the filesystem will already flush all buffers at the OS level (blockdev --flushbufs may still be required if there is a large write cache and you're disconnecting the device immediately after). If the system is in a bad state and you can't unmount, then sync may be the next best thing you can do before rebooting (try to kill all applications that may write to it first).

Also although write caches on the block devices are prone to cause data loss, most modern journaling filesystems cope very well with it, avoiding even the need to run an fsck after a power failure (the filesystem's journal will have everything needed to correct the metadata to a known good state). OTOH the same is usually not true for the file data on the filesystem and you may end up with corrupted files if not flushed properly by badly designed applications.