Date: Sat, 31 Mar 2012 08:15:44 +0200 From: Matthias Andree <matthias.andree@gmx.de> To: freebsd-current@freebsd.org Subject: Re: Using TMPFS for /tmp and /var/run? Message-ID: <4F76A110.4080002@gmx.de> In-Reply-To: <CAJ-VmonpQ7hBxd3k8RmxKmQ0s=EKmvcjmA1Yji6bp24Uc0Cvgg@mail.gmail.com> References: <4F746F1E.6090702@mail.zedat.fu-berlin.de> <4F74BCE8.2030802@vangyzen.net> <CACM2%2B-7Ahn6J=CTASe0g48%2BSD2vvLVd_hG3DRZmvO31QszG5Xw@mail.gmail.com> <20120330.151848.41706133.sthaug@nethelp.no> <CADGWnjXj5W_UCHPExNjxHgq3EZHP1GwocnK4kOHLch5y3gNG0A@mail.gmail.com> <CADLo83-c3jNd9XAyCMhqrEP3x9nvX1=Q9j7foEB37zRy3QZWDA@mail.gmail.com> <CAJ-VmonpQ7hBxd3k8RmxKmQ0s=EKmvcjmA1Yji6bp24Uc0Cvgg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 30.03.2012 21:36, schrieb Adrian Chadd: > Let me tell you a story. > > Someone decided that ext4 could have a decent speed up if it > implemented the posix standard for not flushing files on close(). > After all, if you needed it to be guaranteed to be written to disk, > you would call a flush routine first, before you called close(). > > So they did this. > > Then people testing out ext4 discovered that upon crash, their > kde/gnome profiles were corrupted. > > Why? Because KDE/Gnome authors hadn't ever called flush before > close(), and they weren't the only ones. They didn't read the > standard, they only used the system and fixed bugs whenever their > system behaved against their expectations. They didn't notice that the > system was being different from the standard. > > Guess what ext4 did? :) ext4 sprouted an option (auto_da_alloc, when used with the proper data journalling option data=ordered) to support buggy software. Note that ext4 isn't pioneering the "fsync() required" semantics here, there are other precedents of "0-blocks in files after crash" in Linux file systems, such as XFS. I'm oblivious to the current ext4 defaults WRT these semantics (and I haven't looked at vanilla kernels for a while anyways---distros might have changed default settings).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F76A110.4080002>