fstab - sync writes and async reads?

Gullible Jones · 2010-07-13 13:24:34

Say I'm using XFS. I want to have good read speeds, so mounting the XFS partition sync isn't an option. But I don't want to lose my data either. And I don't want to turn off write caching for the entire drive, since I also have partitions with other filesystems.

Is there a way to mount a filesystem so that only writes are synchronous but not reads, or vice versa? Is that impossible? Do I not know what I'm talking about?

falconindy · 2010-07-13 14:29:55

The 'sync' option has little to do with read speeds. I had a spare partition, so I did a little test:

$  time dd if=/dev/sdb1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 13.7427 s, 78.1 MB/s

real    0m13.759s
user    0m0.734s
sys    0m0.041s

$ sudo mount -o remount,sync /dev/sdb1
$ time dd if=/dev/sdb1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 13.7311 s, 78.2 MB/s

real    0m13.734s
user    0m0.719s
sys    0m0.038s

edit: On second thought, I'm not convinced this is operating at the filesystem level. Anyone know a better test that will circumvent the read caches?

The inverse operation is, of course, tremendously affected by use of synchronous I/O:

$ time dd if=/dev/zero of=foo/zeroes bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 13.59 s, 79.0 MB/s

real    0m13.641s
user    0m0.043s
sys    0m0.909s

$ sudo mount -o remount,sync /dev/sdb1
$ time dd if=/dev/zero of=foo/zeroes bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 54.0264 s, 19.9 MB/s

real    0m54.061s
user    0m0.537s
sys    0m0.592s

The write caching you speak of for the drive is separate from the write caching done on the OS level.

Last edited by falconindy (2010-07-13 14:36:43)

Gullible Jones · 2010-07-13 15:03:24

Ah okay, I had been under the impression that the sync mount option would block any read operation until the one prior to it had finished completely, preventing any sort of parallelism and slowing things down. Must have confused it with something. Didn't know about the hardware write cache either, thanks for enlightening me.

Meanwhile... I've remounted the XFS partition sync and rebooted, and now Firefox is giving me trouble - it grinds the hard drive for minutes at a time, sometimes when rendering pages but usually when just sitting. It seems it is writing huge amounts of stuff somewhere. What on Earth is going on and how can I turn it off?

(I've tried disabling the RSS feeds and the anti-phishing list, but that doesn't seem to do any good; it still grinds like crazy, even while I'm typing this. )

falconindy · 2010-07-13 15:27:30

Is the web cache for firefox on the XFS partition? That would explain a lot. XFS is designed to deal with large files. Personally, I've seen XFS offer dirt poor performance on large numbers of small files -- I inadvertantly had my build directory on an XFS partition for a few days before it occurred to me that unpacking something like the kernel source tarball was taking far too long (over a minute).

I suppose it merits asking: XFS is a journaling filesystem. Why do you want the 'sync' mount option?

tavianator · 2010-07-13 15:43:51

Gullible Jones wrote:

Ah okay, I had been under the impression that the sync mount option would block any read operation until the one prior to it had finished completely, preventing any sort of parallelism and slowing things down. Must have confused it with something. Didn't know about the hardware write cache either, thanks for enlightening me.
Meanwhile... I've remounted the XFS partition sync and rebooted, and now Firefox is giving me trouble - it grinds the hard drive for minutes at a time, sometimes when rendering pages but usually when just sitting. It seems it is writing huge amounts of stuff somewhere. What on Earth is going on and how can I turn it off?
(I've tried disabling the RSS feeds and the anti-phishing list, but that doesn't seem to do any good; it still grinds like crazy, even while I'm typing this. )

Yeah firefox has (IMO) stupid fsync() behaviour, which they insist on keeping on the grounds that they dislike support request like, "I unplugged my computer without shutting it off and lost my bookmarks."

Anyway, XFS is a journaling FS, so is forcing synchronization really going to prevent much data loss? It seems like it's not worth it to lose a factor of 4 on write speed. Do you really have power failures/system crashes/hard shutdowns that often? There's always the "sync" command if you want to be sure a particular thing you do makes it to disk.

Gullible Jones · 2010-07-16 14:18:54

XFS may be a journalling filesystem, but it only journals metadata, and is infamous for losing the data itself on crashes (or overwriting it with garbage).

Gullible Jones · 2010-07-16 14:56:34

Re Firefox's gratuitous fsyncing, it turns out that can be fixed. Add "toolkit.storage.synchronous" as a new integer value in about:config, and set it to 0; this should put a stop to it.

Gullible Jones · 2010-08-15 15:35:17

And an update... As I suspected, general responsiveness is a lot better with sync,nobarrier than with async and barriers. Also certain operations, like untarring packages or writing lots of small files, very obviously take less time. YMMV though, and I don't know how this is for hard drive lifespan.

(Also I'm using the deadline scheduler. According to some benchmarks I've seen CFQ is kind of dodgy with XFS.)

Arch Linux

#1 2010-07-13 13:24:34

fstab - sync writes and async reads?

#2 2010-07-13 14:29:55

Re: fstab - sync writes and async reads?

#3 2010-07-13 15:03:24

Re: fstab - sync writes and async reads?

#4 2010-07-13 15:27:30

Re: fstab - sync writes and async reads?

#5 2010-07-13 15:43:51

Re: fstab - sync writes and async reads?

#6 2010-07-16 14:18:54

Re: fstab - sync writes and async reads?

#7 2010-07-16 14:56:34

Re: fstab - sync writes and async reads?

#8 2010-08-15 15:35:17

Re: fstab - sync writes and async reads?

Board footer