lazytime mount option—no support in Btrfs
Back in 2014 Ted Tso introduced the lazytime mount option for ext4 and shortly thereafter a more generic VFS implementation which was then merged into mainline. His early patches included support for Btrfs but those changes were removed prior to the feature being merged. His changelog includes the following note about the removal:
- Per Christoph's suggestion, drop support for btrfs and xfs for now, issues with how btrfs and xfs handle dirty inode tracking. We can add btrfs and xfs support back later or at the end of this series if we want to revisit this decision.
My reading of the current mainline shows that Btrfs still lacks any support for lazytime. Has any thought been given to adding support for lazytime to Btrfs?
Thanks,
Adam
Quoted 6 lines · Adam Hunt
Back in 2014 Ted Tso introduced the lazytime mount option for ext4 and shortly thereafter a more generic VFS implementation which was then merged into mainline. His early patches included support for Btrfs but those changes were removed prior to the feature being merged. His changelog includes the following note about the removal:
Quoted 8 lines
- Per Christoph's suggestion, drop support for btrfs and xfs for now, issues with how btrfs and xfs handle dirty inode tracking. We can add btrfs and xfs support back later or at the end of this series if we want to revisit this decision.
My reading of the current mainline shows that Btrfs still lacks any support for lazytime. Has any thought been given to adding support for lazytime to Btrfs?
It has bee at least lightly discussed (I forget the thread, but I did a reasonably specific explanation of the interaction of the *atime and lazytime options in a thread a while back when trying to explain to someone why I wanted to be able to run with noatime and lazytime), but I don't think the discussion got anywhere.
I would personally love to see support for it myself (or you know, at least have some warning that it isn't supported instead of just silently accepting and ignoring it like we do currently), but I unfortunately don't have the time or expertise to work on implementing it. If someone does post a patch though, I'll be more than happy to throw a few dozen VM's at testing it.
Quoted 11 lines · Adam Hunt
Back in 2014 Ted Tso introduced the lazytime mount option for ext4 and shortly thereafter a more generic VFS implementation which was then merged into mainline. His early patches included support for Btrfs but those changes were removed prior to the feature being merged. His changelog includes the following note about the removal:
- Per Christoph's suggestion, drop support for btrfs and xfs for now, issues with how btrfs and xfs handle dirty inode tracking. We can add btrfs and xfs support back later or at the end of this series if we want to revisit this decision.
Quoted 8 lines
My reading of the current mainline shows that Btrfs still lacks any support for lazytime. Has any thought been given to adding support for lazytime to Btrfs?
Thanks,
Adam
Is there any new regarding this?
waxhead - 18.08.18, 22:45:
Quoted 17 lines
Quoted 16 lines · Adam Hunt
Back in 2014 Ted Tso introduced the lazytime mount option for ext4 and shortly thereafter a more generic VFS implementation which was then merged into mainline. His early patches included support for Btrfs but those changes were removed prior to the feature being merged. His>
changelog includes the following note about the removal:
- Per Christoph's suggestion, drop support for btrfs and xfs for now,issues with how btrfs and xfs handle dirty inode tracking. We can add btrfs and xfs support back later or at the end of this series if we want to revisit this decision.
My reading of the current mainline shows that Btrfs still lacks any support for lazytime. Has any thought been given to adding support for lazytime to Btrfs?
[…]
Quoted 1 line
Is there any new regarding this?
I´d like to know whether there is any news about this as well.
If I understand it correctly this could even help BTRFS performance a lot cause it is COW´ing metadata.
Thanks,
Signature · 1 line
Martin
Отправлено с iPhone
Quoted 20 lines
19 авг. 2018 г., в 11:37, Martin Steigerwald <[email protected]> написал(а):
waxhead - 18.08.18, 22:45:
Quoted 10 lines
Quoted 9 lines · Adam Hunt
Back in 2014 Ted Tso introduced the lazytime mount option for ext4 and shortly thereafter a more generic VFS implementation which was then merged into mainline. His early patches included support for Btrfs but those changes were removed prior to the feature being merged. His>
changelog includes the following note about the removal:
- Per Christoph's suggestion, drop support for btrfs and xfs for now,Quoted 7 lines
Quoted 7 lines
issues with how btrfs and xfs handle dirty inode tracking. We can add btrfs and xfs support back later or at the end of this series if we want to revisit this decision.
My reading of the current mainline shows that Btrfs still lacks any support for lazytime. Has any thought been given to adding support for lazytime to Btrfs?
Quoted 8 lines
[…]
Quoted 1 line
Is there any new regarding this?
I´d like to know whether there is any news about this as well.
If I understand it correctly this could even help BTRFS performance a lot cause it is COW´ing metadata.
I do not see how btrfs can support it exactly due to cow. Modified atime means checksum no more matches so you must update all related metadata. At which point you have kind of shadow in-memory metadata trees. And if this metadata is not written out, then some other metadata that refers to them becomes invalid.
I suspect any file system that keeps checksums of metadata will run into the same issue.
Quoted 27 lines · Andrei Borzenkov
Отправлено с iPhone
Quoted 23 lines
19 авг. 2018 г., в 11:37, Martin Steigerwald <[email protected]> написал(а):
waxhead - 18.08.18, 22:45:
Quoted 17 lines
Quoted 16 lines · Adam Hunt
Back in 2014 Ted Tso introduced the lazytime mount option for ext4 and shortly thereafter a more generic VFS implementation which was then merged into mainline. His early patches included support for Btrfs but those changes were removed prior to the feature being merged. His>
changelog includes the following note about the removal:
- Per Christoph's suggestion, drop support for btrfs and xfs for now,issues with how btrfs and xfs handle dirty inode tracking. We can add btrfs and xfs support back later or at the end of this series if we want to revisit this decision.
My reading of the current mainline shows that Btrfs still lacks any support for lazytime. Has any thought been given to adding support for lazytime to Btrfs?
[…]
Quoted 1 line
Is there any new regarding this?
Quoted 7 lines
Quoted 5 lines
I´d like to know whether there is any news about this as well.
If I understand it correctly this could even help BTRFS performance a lot cause it is COW´ing metadata.
I do not see how btrfs can support it exactly due to cow. Modified atime means checksum no more matches so you must update all related metadata. At which point you have kind of shadow in-memory metadata trees. And if this metadata is not written out, then some other metadata that refers to them becomes invalid.
I think you might be misunderstanding something here, either how lazytime actually works, or how BTRFS checksumming works.
Lazytime prevents timestamp updates from triggering writeback of a cached inode. Other changes will trigger writeback, as will anything that evicts the inode from the cache, and an automatic writeback will be triggered if the timestamp changed more than 24 hours ago, but until any of those situations happens, no writeback will be triggered.
BTRFS checksumming only verifies checksums of blocks which are being read. If the inode is in the cache (which it has to be for lazytime to have _any_ effect on it), the block containing it on disk does not need to be read, so no checksum verification happens. Even if there was verification, we would not be verifying blocks that are in memory using the on-disk checksums (because that would break writeback caching, which we already do and already works correctly).
So, given all this, the only inconsistency on-disk for BTRFS with this would be identical to the inconsistency it causes for other filesystems, namely that mtimes and atimes may not be accurate.
Also, slightly OT, but atimes are not where the real benefit is here for most people. No sane software other than mutt uses atimes (and mutt's use of them is not sane, but that's a different argument), so pretty much everyone who wants to avoid the overhead from them can just use the noatime mount option. The real benefit for most people is with mtimes, for which there is no other way to limit the impact they have on performance.
Quoted 3 lines
I suspect any file system that keeps checksums of metadata will run into the same issue.
Nope, only if they verify checksums on stuff that's already cached _and_ they pull the checksums for verification from the block device and not the cache.
Quoted 3 lines · Austin S. Hemmelgarn
Also, slightly OT, but atimes are not where the real benefit is here for most people. No sane software other than mutt uses atimes (and mutt's use of them is not sane, but that's a different argument)
Right. There are two competing forks of mutt: neomutt and vanilla:
https://github.com/neomutt/neomutt/commit/816095bfdb72caafd8845e8fb28cbc8c6afc114f
https://gitlab.com/dops/mutt/commit/489a1c394c29e4b12b705b62da413f322406326f
So this has already been taken care of.
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.
atime updates (including relatime) are bad not only for performance, they also explode disk size used by snapshots (btrfs, LVM, ...) -- to the tune of ~5% per snapshot for some non-crafted loads. And, are bad for media with low write endurance (SD cards, as used by most SoCs).
Thus, atime needs to die.
Quoted 2 lines
The real benefit for most people is with mtimes, for which there is no other way to limit the impact they have on performance.
With btrfs, any write already triggers metadata update (except nocow), thus there's little benefit of lazytime for mtimes.
Meow!
Signature · 4 lines
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water [Mt14:25-26]
Quoted 19 lines · Adam Borowski
Quoted 3 lines · Austin S. Hemmelgarn
Also, slightly OT, but atimes are not where the real benefit is here for most people. No sane software other than mutt uses atimes (and mutt's use of them is not sane, but that's a different argument)
Right. There are two competing forks of mutt: neomutt and vanilla:
https://github.com/neomutt/neomutt/commit/816095bfdb72caafd8845e8fb28cbc8c6afc114f
https://gitlab.com/dops/mutt/commit/489a1c394c29e4b12b705b62da413f322406326fSo this has already been taken care of.
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.atime updates (including relatime) are bad not only for performance, they also explode disk size used by snapshots (btrfs, LVM, ...) -- to the tune of ~5% per snapshot for some non-crafted loads. And, are bad for media with low write endurance (SD cards, as used by most SoCs).
Quoted 7 lines
Thus, atime needs to die.
Quoted 2 lines
The real benefit for most people is with mtimes, for which there is no other way to limit the impact they have on performance.
With btrfs, any write already triggers metadata update (except nocow), thus there's little benefit of lazytime for mtimes.
But does that actually propagate all the way up to the point of updating the inode itself? If so, then yes, there is not really any point. if not though, then there is still a benefit.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.
It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).
Quoted 12 lines · Janos Toth F.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).
Last I knew, it was fixed. Of course, it's been quite a while since I last tried this, as I run locally patched kernels that have noatime as the default instead of relatime.
Also, once you've got the space cache set up by mounting once writable with the appropriate flag and then waiting for it to initialize, you should not ever need to specify the space_cache option again.
Quoted 13 lines · Austin S. Hemmelgarn
Quoted 12 lines · Janos Toth F.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).
Quoted 3 lines
Last I knew, it was fixed. Of course, it's been quite a while since I last tried this, as I run locally patched kernels that have
noatimeas the default instead ofrelatime.
I'm using VMs without initrd, tested the rootflags=noatime and it still fails, the same way as in the bugreport.
As the 'noatime' mount option is part of the mount(2) API (passed as a bit via mountflags), the remaining option in the filesystem is to whitelist the generic options and ignore them. But this brings some layering violation question.
On the other hand, this would be come confusing as the user expectation is to see the effects of 'noatime'.
Quoted 21 lines · David Sterba
Quoted 13 lines · Austin S. Hemmelgarn
Quoted 12 lines · Janos Toth F.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).Quoted 3 lines
Last I knew, it was fixed. Of course, it's been quite a while since I last tried this, as I run locally patched kernels that have
noatimeas the default instead ofrelatime.I'm using VMs without initrd, tested the rootflags=noatime and it still fails, the same way as in the bugreport.
Quoted 8 lines
As the 'noatime' mount option is part of the mount(2) API (passed as a bit via mountflags), the remaining option in the filesystem is to whitelist the generic options and ignore them. But this brings some layering violation question.
On the other hand, this would be come confusing as the user expectation is to see the effects of 'noatime'.
Ideally there would be a way to get this to actually work properly. I think ext4 at least doesn't panic, though I'm not sure if it actually works correctly.
Otherwise, the only option for people who want it set is to patch the kernel to get noatime as the default (instead of relatime). I would look at pushing such a patch upstream myself actually, if it weren't for the fact that I'm fairly certain that it would be immediately NACK'ed by at least Linus, and probably a couple of other people too.
Austin S. Hemmelgarn posted on Tue, 21 Aug 2018 13:01:00 -0400 as excerpted:
Quoted 5 lines
Otherwise, the only option for people who want it set is to patch the kernel to get noatime as the default (instead of relatime). I would look at pushing such a patch upstream myself actually, if it weren't for the fact that I'm fairly certain that it would be immediately NACK'ed by at least Linus, and probably a couple of other people too.
What about making default-noatime a kconfig option, presumably set to default-relatime by default? That seems to be the way many legacy- incompatible changes work. Then for most it's up to the distro, which in fact it is already, only if the distro set noatime-default they'd at least be using an upstream option instead of patching it themselves, making it upstream code that could be accounted for instead of downstream code that... who knows?
Meanwhile, I'd be interested in seeing your local patch. I'm local- patching noatime-default here too, but not being a dev, I'm not entirely sure I'm doing it "correctly", tho AFAICT it does seem to work. FWIW, here's what I'm doing (posting inline so may be white-space damaged, and IIRC I just recently manually updated the line numbers so they don't reflect the code at the 2014 date any more, but as I'm not sure of the "correctness" it's not intended to be applied in any case):
namespace.c renamed from namespace.c.orig +5 -2
@@ -2823,8 +2823,9 @@ long do_mount(const char *dev_name, cons goto dput_out;/* Default to relatime unless overriden */ -if (!(flags &MS_NOATIME )) - mnt_flags |=MNT_RELATIME ; +/* JED: Make that noatime */ +if (!(flags &MS_RELATIME )) + mnt_flags |=MNT_NOATIME ;/* Separate the per-mountpoint flags */ if (flags &MS_NOSUID )
@@ -2837,6 +2837,8 @@ long do_mount(const char *dev_name, cons mnt_flags |=MNT_NOATIME ;if (flags &MS_NODIRATIME ) mnt_flags |=MNT_NODIRATIME ; +if (flags &MS_RELATIME ) + mnt_flags |=MNT_RELATIME ;if (flags &MS_STRICTATIME ) mnt_flags &= ~(MNT_RELATIME |MNT_NOATIME );if (flags &MS_RDONLY )
Sane, or am I "doing it wrong!"(TM), or perhaps doing it correctly, but missing a chunk that should be applied elsewhere?
Meanwhile, since broken rootflags requiring an initr* came up let me take the opportunity to ask once again, does btrfs-raid1 root still require an initr*? It'd be /so/ nice to be able to supply the appropriate rootflags=device=...,device=... and actually have it work so I didn't need the initr* any longer!
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 9 lines · Duncan
Austin S. Hemmelgarn posted on Tue, 21 Aug 2018 13:01:00 -0400 as excerpted:
Quoted 5 lines
Otherwise, the only option for people who want it set is to patch the kernel to get noatime as the default (instead of relatime). I would look at pushing such a patch upstream myself actually, if it weren't for the fact that I'm fairly certain that it would be immediately NACK'ed by at least Linus, and probably a couple of other people too.
Quoted 7 lines
What about making default-noatime a kconfig option, presumably set to default-relatime by default? That seems to be the way many legacy- incompatible changes work. Then for most it's up to the distro, which in fact it is already, only if the distro set noatime-default they'd at least be using an upstream option instead of patching it themselves, making it upstream code that could be accounted for instead of downstream code that... who knows?
That's probably a lot more likely to make it upstream, but it's a bit beyond my skills when it comes to stuff like this.
Quoted 33 lines
Meanwhile, I'd be interested in seeing your local patch. I'm local- patching noatime-default here too, but not being a dev, I'm not entirely sure I'm doing it "correctly", tho AFAICT it does seem to work. FWIW, here's what I'm doing (posting inline so may be white-space damaged, and IIRC I just recently manually updated the line numbers so they don't reflect the code at the 2014 date any more, but as I'm not sure of the "correctness" it's not intended to be applied in any case):
namespace.c renamed from namespace.c.orig +5
-2@@ -2823,8 +2823,9 @@ long do_mount(const char *dev_name, cons goto dput_out;/* Default to relatime unless overriden */ -if (!(flags &MS_NOATIME )) - mnt_flags |=MNT_RELATIME ; +/* JED: Make that noatime */ +if (!(flags &MS_RELATIME )) + mnt_flags |=MNT_NOATIME ;/* Separate the per-mountpoint flags */ if (flags &MS_NOSUID )@@ -2837,6 +2837,8 @@ long do_mount(const char *dev_name, cons mnt_flags |=MNT_NOATIME ;if (flags &MS_NODIRATIME ) mnt_flags |=MNT_NODIRATIME ; +if (flags &MS_RELATIME ) + mnt_flags |=MNT_RELATIME ;if (flags &MS_STRICTATIME ) mnt_flags &= ~(MNT_RELATIME |MNT_NOATIME );if (flags &MS_RDONLY )
Quoted 2 lines
Sane, or am I "doing it wrong!"(TM), or perhaps doing it correctly, but missing a chunk that should be applied elsewhere?
Mine only has the first part, not the second, which seems to cover making sure it's noatime by default. I never use relatime though, so that may be broken with my patch because of me not having the second part.
Quoted 7 lines
Meanwhile, since broken rootflags requiring an initr* came up let me take the opportunity to ask once again, does btrfs-raid1 root still require an initr*? It'd be /so/ nice to be able to supply the appropriate rootflags=device=...,device=... and actually have it work so I didn't need the initr* any longer!
Last I knew, specifying appropriate device= options in rootflags works correctly without an initrd.
Quoted 27 lines · Austin S. Hemmelgarn
Quoted 26 lines · David Sterba
Quoted 13 lines · Austin S. Hemmelgarn
Quoted 12 lines · Janos Toth F.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).Quoted 3 lines
Last I knew, it was fixed. Of course, it's been quite a while since I last tried this, as I run locally patched kernels that have
noatimeas the default instead ofrelatime.I'm using VMs without initrd, tested the rootflags=noatime and it still fails, the same way as in the bugreport.
As the 'noatime' mount option is part of the mount(2) API (passed as a bit via mountflags), the remaining option in the filesystem is to whitelist the generic options and ignore them. But this brings some layering violation question.
Quoted 6 lines
Quoted 3 lines
On the other hand, this would be come confusing as the user expectation is to see the effects of 'noatime'.
Ideally there would be a way to get this to actually work properly. I think ext4 at least doesn't panic, though I'm not sure if it actually works correctly.
No, ext4 also refuses to mount, the panic happens in VFS that tries either the rootfstype= or all available filesystems.
[ 3.763602] EXT4-fs (sda): Unrecognized mount option "noatime" or missing value
[ 3.761315] BTRFS info (device sda): unrecognized mount option 'noatime'
Quoted 5 lines
Otherwise, the only option for people who want it set is to patch the kernel to get noatime as the default (instead of relatime). I would look at pushing such a patch upstream myself actually, if it weren't for the fact that I'm fairly certain that it would be immediately NACK'ed by at least Linus, and probably a couple of other people too.
An acceptable solution could be to parse the rootflags and translate them to the MNT_* values, ie. what the commandline tool mount does before it calls the mount syscall.
Quoted 48 lines · David Sterba
Quoted 27 lines · Austin S. Hemmelgarn
Quoted 26 lines · David Sterba
Quoted 13 lines · Austin S. Hemmelgarn
Quoted 12 lines · Janos Toth F.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).Quoted 3 lines
Last I knew, it was fixed. Of course, it's been quite a while since I last tried this, as I run locally patched kernels that have
noatimeas the default instead ofrelatime.I'm using VMs without initrd, tested the rootflags=noatime and it still fails, the same way as in the bugreport.
As the 'noatime' mount option is part of the mount(2) API (passed as a bit via mountflags), the remaining option in the filesystem is to whitelist the generic options and ignore them. But this brings some layering violation question.
Quoted 6 lines
Quoted 3 lines
On the other hand, this would be come confusing as the user expectation is to see the effects of 'noatime'.
Ideally there would be a way to get this to actually work properly. I think ext4 at least doesn't panic, though I'm not sure if it actually works correctly.
No, ext4 also refuses to mount, the panic happens in VFS that tries either the rootfstype= or all available filesystems.
[ 3.763602] EXT4-fs (sda): Unrecognized mount option "noatime" or missing value[ 3.761315] BTRFS info (device sda): unrecognized mount option 'noatime'Quoted 5 lines
Otherwise, the only option for people who want it set is to patch the kernel to get noatime as the default (instead of relatime). I would look at pushing such a patch upstream myself actually, if it weren't for the fact that I'm fairly certain that it would be immediately NACK'ed by at least Linus, and probably a couple of other people too.
Quoted 4 lines
An acceptable solution could be to parse the rootflags and translate them to the MNT_* values, ie. what the commandline tool mount does before it calls the mount syscall.
That would be helpful, but at that point you might as well update the CLI mount tool to just pass all the named options to the kernel and have it do the parsing (I mean, keep the old interface too obviously, but provide a new one and use that preferentially).
I also like Duncan's suggestion to expose the default value for the atime options as a kconfig option (Chris Murphy emailed me directly about essentially the same thing).
Quoted 49 lines · Austin S. Hemmelgarn
Quoted 48 lines · David Sterba
Quoted 27 lines · Austin S. Hemmelgarn
Quoted 26 lines · David Sterba
Quoted 13 lines · Austin S. Hemmelgarn
Quoted 12 lines · Janos Toth F.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).Quoted 3 lines
Last I knew, it was fixed. Of course, it's been quite a while since I last tried this, as I run locally patched kernels that have
noatimeas the default instead ofrelatime.I'm using VMs without initrd, tested the rootflags=noatime and it still fails, the same way as in the bugreport.
As the 'noatime' mount option is part of the mount(2) API (passed as a bit via mountflags), the remaining option in the filesystem is to whitelist the generic options and ignore them. But this brings some layering violation question.
Quoted 6 lines
Quoted 3 lines
On the other hand, this would be come confusing as the user expectation is to see the effects of 'noatime'.
Ideally there would be a way to get this to actually work properly. I think ext4 at least doesn't panic, though I'm not sure if it actually works correctly.
No, ext4 also refuses to mount, the panic happens in VFS that tries either the rootfstype= or all available filesystems.
[ 3.763602] EXT4-fs (sda): Unrecognized mount option "noatime" or missing value[ 3.761315] BTRFS info (device sda): unrecognized mount option 'noatime'Quoted 5 lines
Otherwise, the only option for people who want it set is to patch the kernel to get noatime as the default (instead of relatime). I would look at pushing such a patch upstream myself actually, if it weren't for the fact that I'm fairly certain that it would be immediately NACK'ed by at least Linus, and probably a couple of other people too.
Quoted 8 lines
Quoted 4 lines
An acceptable solution could be to parse the rootflags and translate them to the MNT_* values, ie. what the commandline tool mount does before it calls the mount syscall.
That would be helpful, but at that point you might as well update the CLI mount tool to just pass all the named options to the kernel and have it do the parsing (I mean, keep the old interface too obviously, but provide a new one and use that preferentially).
The initial mount is not done by the mount tool but internally by kernel init sequence (files in init/):
mount_block_root
do_mount_root
ksys_mount
The mount options (as a string) is passed unchanged via variable root_mount_data (== rootflags). So before this step, the options would have to be filtered and all known generic options turned into bit flags.
Quoted 62 lines · David Sterba
Quoted 49 lines · Austin S. Hemmelgarn
Quoted 48 lines · David Sterba
Quoted 27 lines · Austin S. Hemmelgarn
Quoted 26 lines · David Sterba
Quoted 13 lines · Austin S. Hemmelgarn
Quoted 12 lines · Janos Toth F.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
so pretty much everyone who wants to avoid the overhead from them can just use the
noatimemount option.It would be great if someone finally fixed this old bug then:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
Until then, it seems practically impossible to use both noatime (this can't be added as rootflag in the command line and won't apply if the kernel already mounted the root as RW) and space-cache-v2 (has to be added as a rootflag along with RW to take effect) for the root filesystem (at least without an init*fs, which I never use, so can't tell).Quoted 3 lines
Last I knew, it was fixed. Of course, it's been quite a while since I last tried this, as I run locally patched kernels that have
noatimeas the default instead ofrelatime.I'm using VMs without initrd, tested the rootflags=noatime and it still fails, the same way as in the bugreport.
As the 'noatime' mount option is part of the mount(2) API (passed as a bit via mountflags), the remaining option in the filesystem is to whitelist the generic options and ignore them. But this brings some layering violation question.
Quoted 6 lines
Quoted 3 lines
On the other hand, this would be come confusing as the user expectation is to see the effects of 'noatime'.
Ideally there would be a way to get this to actually work properly. I think ext4 at least doesn't panic, though I'm not sure if it actually works correctly.
No, ext4 also refuses to mount, the panic happens in VFS that tries either the rootfstype= or all available filesystems.
[ 3.763602] EXT4-fs (sda): Unrecognized mount option "noatime" or missing value[ 3.761315] BTRFS info (device sda): unrecognized mount option 'noatime'Quoted 5 lines
Otherwise, the only option for people who want it set is to patch the kernel to get noatime as the default (instead of relatime). I would look at pushing such a patch upstream myself actually, if it weren't for the fact that I'm fairly certain that it would be immediately NACK'ed by at least Linus, and probably a couple of other people too.
Quoted 8 lines
Quoted 4 lines
An acceptable solution could be to parse the rootflags and translate them to the MNT_* values, ie. what the commandline tool mount does before it calls the mount syscall.
That would be helpful, but at that point you might as well update the CLI mount tool to just pass all the named options to the kernel and have it do the parsing (I mean, keep the old interface too obviously, but provide a new one and use that preferentially).
The initial mount is not done by the mount tool but internally by kernel init sequence (files in
init/):
Quoted 8 lines
mount_block_root
do_mount_root
ksys_mountThe mount options (as a string) is passed unchanged via variable
root_mount_data(== rootflags). So before this step, the options would have to be filtered and all known generic options turned into bit flags.
What I'm saying is that if there's going to be parsing for it in the kernel anyway, why not expose that interface to userspace too so that the regular mount tool can take advantage of it as well.
Austin S. Hemmelgarn posted on Wed, 22 Aug 2018 07:30:09 -0400 as excerpted:
Quoted 8 lines
Quoted 5 lines
Meanwhile, since broken rootflags requiring an initr* came up let me take the opportunity to ask once again, does btrfs-raid1 root still require an initr*? It'd be /so/ nice to be able to supply the appropriate rootflags=device=...,device=... and actually have it work so I didn't need the initr* any longer!
Last I knew, specifying appropriate
device=options in rootflags works correctly without an initrd.
Just to confirm, that's with multi-device btrfs rootfs? Because it used to work when the btrfs was single-device, but not multi-device.
(For multi-device, or at least raid1, one had to add degraded, also, or it would refuse to mount despite all the appropriate device= entries in rootflags, thus of course risking all the problems running degraded raid1 operationally can bring, tho I never figured out for sure whether btrfs was smart enough to eventually pick up the other devices, after the scan before bringing other btrfs online or not, but either way it was a risk I wasn't willing to take.)
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 3 lines · Austin S. Hemmelgarn
Also, once you've got the space cache set up by mounting once writable with the appropriate flag and then waiting for it to initialize, you should not ever need to specify the
space_cacheoption again.
True.
I am not sure why I thought I have to keep cache-v2 in the rootflag list. I guess I forgot it was meant to be removed after a reboot. Or may be some old kernels misbehaved (always cleared the space-tree for some reason and re-initialized a space-cache instead unless the flag was there). But I removed it now and everything works as intended. Thanks.