-   Linux - Newbie (
-   -   fsync, sync: does it really do what its supposed to? (

sanrio alvares 09-04-2012 06:07 AM

fsync, sync: does it really do what its supposed to?
I would like to have more clarification on the functionality of sync(8) and fsync functions in Linux (2.6.31). Does it make sure the files are written to the respective storage?

MensaWater 09-04-2012 09:51 AM

It attempts to do so but there are caveats in the man and info pages. To read more documentation on your system you can run the commands:

man 8 sync

man 2 sync

info sync

man fsync

You will see the sync command (man section 8/info sync) just invokes the sync system call (man section 2).

One note seen for sync is:

According to the standard specification (e.g., POSIX.1-2001), sync()
schedules the writes, but may return before the actual writing is done.
However, since version 1.3.20 Linux does actually wait. (This still
does not guarantee data integrity: modern disks have large caches.)
It depends much on where the write is going. As noted above disks themselves have cache. Additionally if you're using a SCSI/RAID disk controller it might have its own cache. If you're writing to an external disk array via fibre or iSCSI it is likely the disk array itself has caching of its own. The key point to remember is that when it says it flushes or writes it what it really means is it has told the memory of the server itself to immediately send it to the storage. How quickly it actually gets physically on the disk depends on the storage itself. In some cases it doesn't really matter (e.g. the external disk array - once the sync has sent the command to the HBA and the HBA has sent to the array then it doesn't matter if the host goes down as the actual write to disk is handled by the array).

Also this is why journaling filesystems such as ext3/vxfs were created. They create intent logs that are more frequently updated than actual writes to disk so in the event of a crash when you run fsck after a boot it will find uncommited extents and update the disk.

Although you CAN lose data in a system crash in practice it doesn't really happen very often. However, ideally you should have redundant power to allow for orderly shutdowns on loss of power because losing data writes especially in DBMS setups CAN cause corruption so you want to avoid it if at all possible.

sanrio alvares 09-05-2012 01:10 AM

Thanks for the reply. That explains a lot to me.
One more thing id like to know, does the MMC/SD controller on a mobile chipset have the ability to cache data? I can see the SD host driver sending the data when there is a write to the SD card. Does this imply that the data is written to the SD card immediately or is there caching done by the SD controller before finally writing to the SD card?
The Chipset Specification does not say that the SD Controller has caching capability though.

MensaWater 09-05-2012 09:26 AM

Since SD is essentially memory itself I'd think there'd be little benefit to having a write cache to it but again your best bet is knowing exactly what it is and looking on line for details about what it has. Mobile chipsets are designed for very cramped conditions so I think it unlikely they'd waste space on write caches.

Just looking generically for MMC/SD cache in a web search I found a controller that has read cache built into it. However, this isn't for a mobile device.
Notice that it does NOT say it has write cache so presumably it doesn't and a sync would therefore write directly to it.

Again you'd have to know specifically what it is (vendor/model) and look for the features of same in a web search.

All times are GMT -5. The time now is 06:35 PM.