2

Does it make any sense to run sync after umount during a clean shutdown? I assume that umount will write to disk any cached data.

The only odd case I can think of is when you have some loop device (like a LUKS container) on the top of your real disk.

Umount might try to unmount the partition first. And it might not be able to unmount a partition until the loop device is unmounted. But would it sync the data anyway in this case?

1

sync affects file systems only, not block devices.

An interesting question (not related to unmounting) which I cannot answer, though, is this: In which order does sync treat the file systems? If it first flushes the cache for the root filesystem and then that of the loop device filesystem then the second flush created new caches data for the root filesystem so that there may never be a moment where everything is completely clean. But the kernel may wait until all filesystem caches report being clean before returning the sync() syscall.

But you may call sync with a file argument and call it several times in the right order if you do not trust the kernel to do it right...

0

No, it doesn't make any sense to run sync after (a successful) umount.

The umount already syncs any pending writes to the filesystem. The sync command syncs cached filesystem data of mounted filesystems.

The dm-crypt device configured by LUKS nowadays correctly passes through flush commands (cf. cryptsetup FAQ item 2.13 If I map a journaled file system using dm-crypt/LUKS, does it still provide its usual transactional guarantees?).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.