Am Mon, 10 Apr 2017 15:43:57 -0400 schrieb "Austin S. Hemmelgarn" <ahferro...@gmail.com>:
> On 2017-04-10 14:18, Kai Krakow wrote: > > Am Mon, 10 Apr 2017 13:13:39 -0400 > > schrieb "Austin S. Hemmelgarn" <ahferro...@gmail.com>: > > > >> On 2017-04-10 12:54, Kai Krakow wrote: > [...] > [...] > >> [...] > >> [...] > [...] > >> [...] > >> [...] > [...] > [...] > >> The command-line also rejects a number of perfectly legitimate > >> arguments that BTRFS does understand too though, so that's not much > >> of a test. > > > > Which are those? I didn't encounter any... > I'm not sure there are any anymore, but I know that a handful (mostly > really uncommon ones) used to (and BTRFS is not alone in this > respect, some of the more esoteric ext4 options aren't accepted on > the kernel command-line either). I know at a minimum at some point > in the past alloc-start, check_int, and inode_cache did not work from > the kernel command-line. The post from Janos explains why: The difference is with the mount handler, depending on whether you use initrd or not. > >> I've just finished some quick testing though, and it looks > >> like you're right, BTRFS does not support this, which means I now > >> need to figure out what the hell was causing the IOPS counters in > >> collectd to change in rough correlation with remounting > >> (especially since it appears to happen mostly independent of the > >> options being changed). > > > > I think that noatime (which I remember you also used?), lazytime, > > and relatime are mutually exclusive: they all handle the inode > > updates. Maybe that is the effect you see? > They're not exactly exclusive. The lazytime option will prevent > changes to the mtime or atime fields in a file from forcing inode > write-out for up to 24 hours (if the inode would be written out for > some other reason (such as a file-size change or the inode being > evicted from the cache), then the timestamps will be too), but it > does not change the value of the timestamps. So if you have lazytime > enabled and use touch to update the mtime on anotherwise idle file, > the mtime will still be correct as far as userspace is concerned, as > long as you don't crash before the update hits the disk (but > userspace will only see the discrepancy _after_ the crash). Yes, I know all this. But I don't see why you still want noatime or relatime if you use lazytime, except for super-optimizing. Lazytime gives you POSIX conformity for a problem that the other options only tried to solve. > > Well, relatime is mostly the same thus not perfectly resembling the > > POSIX standard. I think the only software that relies on atime is > > mutt... > This very much depends on what you're doing. If you have a WORM > workload, then yeah, it's pretty much the same. If however you have > something like a database workload where a specific set of files get > internally rewritten regularly, then it actually has a measurable > impact. I think "impact" is a whole different story. I'm on your side here. -- Regards, Kai Replies to list-only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
