What is the difference between sync and async mount options from the end-user point of view? Is file system mounted with one of these options works faster than if mounted with another one? Which option is the default one, if none of them is set?

man mount says that sync option may reduce lifetime of flash memory, but it may by obsolete conventional wisdom. Anyway this concerns me a bit, because my primary hard drive, where partitions / and /home are placed, is SSD drive.

Ubuntu installer (14.04) have not specified sync nor async option for / partition, but have set async for /home by the option defaults. Here is my /etc/fstab, I added some additional lines (see comment), but not changed anything in lines made by installer:

# / was on /dev/sda2 during installation
UUID=7e4f7654-3143-4fe7-8ced-445b0dc5b742 /     ext4  errors=remount-ro 0  1
# /home was on /dev/sda3 during installation
UUID=d29541fc-adfa-4637-936e-b5b9dbb0ba67 /home ext4  defaults          0  2
# swap was on /dev/sda4 during installation
UUID=f9b53b49-94bc-4d8c-918d-809c9cefe79f none  swap  sw                0  0

# here goes part written by me:

# /mnt/storage
UUID=4e04381d-8d01-4282-a56f-358ea299326e /mnt/storage ext4 defaults  0  2
# Windows C: /dev/sda1
UUID=2EF64975F6493DF9   /mnt/win_c    ntfs    auto,umask=0222,ro      0  0
# Windows D: /dev/sdb1
UUID=50C40C08C40BEED2   /mnt/win_d    ntfs    auto,umask=0222,ro      0  0

So if my /dev/sda is SSD, should I - for the sake of reducing wear - add async option for / and /home file systems? Should I set sync or async option for additional partitions that I defined in my /etc/fstab? What is recommended approach for SSD and HDD drives?


async is the opposite of sync, which is rarely used. async is the default, you don't need to specify that explicitly.

The option sync means that all changes to the according filesystem are immediately flushed to disk; the respective write operations are being waited for. For mechanical drives that means a huge slow down since the system has to move the disk heads to the right position; with sync the userland process has to wait for the operation to complete. In contrast, with async the system buffers the write operation and optimizes the actual writes; meanwhile, instead of being blocked the process in userland continues to run. (If something goes wrong, then close() returns -1 with errno = EIO.)

SSD: I don't know how fast the SSD memory is compared to RAM memory, but certainly it is not faster, so sync is likely to give a performance penalty, although not as bad as with mechanical disk drives. As of the lifetime, the wisdom is still valid, since writing to a SSD a lot "wears" it off. The worst scenario would be a process that makes a lot of changes to the same place; with sync each of them hits the SSD, while with async (the default) the SSD won't see most of them due to the kernel buffering.

In the end of the day, don't bother with sync, it's most likely that you're fine with async.

  • in the case that a local application is deleting and writing to the mounted drive (pointing to an external Windows box); is there potential that the default, async mode is unsafe? The scenario is a polling app, looking in one folder on the mount, pocessing the sub folders then deleting them. – HellishHeat Jun 17 '15 at 8:50
  • @HellishHeat You should ask this as a separate question with sufficient details of the scenario you have in mind. – countermode Aug 21 '17 at 14:53
  • What is the speed of different storage layers: ram is nanosecond, flash is microseconds ( 10's for writes, about 100 for reads ), rotational disk is milliseconds ( 5 ms best case, 10 to 100ms if the disk queue is backed up and the accesses are random ). Writes to a single location on a flash device may write to a capacitor backed SRAM and not be written all the way to NAND. Thus it is hard to determine either wear or speed impact. – Brian Bulkowski Mar 12 '18 at 19:11
  • Does this mean one doesn't need to call sync or fsync or fdatasync syscalls on a sync mounted fs? – CMCDragonkai Sep 21 '18 at 3:40
  • 1
    @ini You may risk a loss of data with async. Yet, if this is an issue, then sync is not the answer - the performance penalty of sync is simply prohibitive. – countermode Dec 9 '18 at 6:02

Words of caution: using the 'async' mount option might not be the best idea if you have a mount that is constantly being written to (ex. valuable logs, security camera recordings, etc.) and you are not protected from sudden power outages. It might result in missing records or incomplete (useless) data. Not-so-smart example: imagine a thief getting into a store and immediately cutting the camera power cable. The video recording of the break-in was recorded but might not have been flushed/synced to the disk since it (or parts of it) might have been buffered in memory instead, thus got lost when the camera lost power.

  • 1
    Modern servers have battery backed disk caches in RAID controllers, which will prevent from data loss even in case of a power loss. – tonioc Jun 8 '18 at 11:59
  • async does not write for many seconds? How many seconds approximately? – Ini Dec 9 '18 at 1:00
  • @Ini seems it depends on the filesystem being used I believe. – bjd2385 Dec 17 '18 at 3:21
  • 1
    The OS should anyway ensure that when you shutdown, that everything gets written to the ssd/hdd. In the case of a power-outage then you might loose some data. Is what I'm saying correct? – Ini Dec 17 '18 at 11:28
  • 2
    Battery-based cache in some disks is really not a reason to not optimize for power loss 1) that's only in expensive professional servers. Not all users will have this 2) it will only save you in the situation where the data has even reached the disk controller at all. In many cases it will be stuck in OS cache, long before the controller will ever see that data - and that will be lost in an event of a power failure. – Cray Mar 28 '19 at 20:45

Your Answer

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