* btrfs mount flags
@ 2012-04-13 15:50 Kai Krakow
2012-04-13 17:42 ` Duncan
2012-04-13 22:05 ` Martin Steigerwald
0 siblings, 2 replies; 7+ messages in thread
From: Kai Krakow @ 2012-04-13 15:50 UTC (permalink / raw)
To: linux-btrfs
Hello!
Is there any documentation about btrfs mount flags wrt:
1. which flags are one-time options and are permanent,
2. which flags are global per btrfs partition,
3. which flags are local per subvolume mount?
I'm asking because while googling I found very confusing info about
autodefrag. Some say it is a global flag, others say to get autodefrag one
has to supply it for each subvolume mount to have autodefrag for that
subvolume.
Then there's space_cache which is a one-time option and does not need to be
given on successive mounts. Otoh there's inode_cache which I would expect to
be handled the same but it doesn't look like it's implemented that way.
Then maybe there are flags which are obsolete meanwhile because they are
default features with later kernel versions.
Thanks,
Kai
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs mount flags
2012-04-13 15:50 btrfs mount flags Kai Krakow
@ 2012-04-13 17:42 ` Duncan
2012-04-14 15:17 ` Kai Krakow
2012-04-13 22:05 ` Martin Steigerwald
1 sibling, 1 reply; 7+ messages in thread
From: Duncan @ 2012-04-13 17:42 UTC (permalink / raw)
To: linux-btrfs
Kai Krakow posted on Fri, 13 Apr 2012 17:50:45 +0200 as excerpted:
> Is there any documentation about btrfs mount flags wrt:
AFAIK the best documentation is the wiki, which you didn't mention, tho
you mentioned google. It's also possible that you found the old/outdated
(because it's read-only after the kernel.org breakin some months ago) wiki
on btrfs.wiki.kernel.org, but not the current (but possibly temporary)
one linked below.
So the wiki is where I'd go first. Questions you have after that, ask
here, and preferably update the wiki with the answers you get, as well.
http://btrfs.ipv5.de/index.php?title=Main_Page
--
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs mount flags
2012-04-13 15:50 btrfs mount flags Kai Krakow
2012-04-13 17:42 ` Duncan
@ 2012-04-13 22:05 ` Martin Steigerwald
1 sibling, 0 replies; 7+ messages in thread
From: Martin Steigerwald @ 2012-04-13 22:05 UTC (permalink / raw)
To: linux-btrfs; +Cc: Kai Krakow
Am Freitag, 13. April 2012 schrieb Kai Krakow:
> Hello!
Hi!
> Is there any documentation about btrfs mount flags wrt:
>
> 1. which flags are one-time options and are permanent,
> 2. which flags are global per btrfs partition,
> 3. which flags are local per subvolume mount?
>
> I'm asking because while googling I found very confusing info about
> autodefrag. Some say it is a global flag, others say to get autodefrag
> one has to supply it for each subvolume mount to have autodefrag for
> that subvolume.
>
> Then there's space_cache which is a one-time option and does not need
> to be given on successive mounts. Otoh there's inode_cache which I
> would expect to be handled the same but it doesn't look like it's
> implemented that way.
I like the distinction in Ext3/Ext4. There are mount option and filesystem
features that can be activated at mkfs time or (some) later with tune2fs.
Now I would expect a one time mount option to be a filesystem feature that
I enabled with btrfstune or so. Cause I always understood mount options as
temporary unless I write them into /etc/fstab. But then tune2fs / Ext also
supports default mount options, so you could encode into the fs as well.
There even is a btrfstune command and it has a switch to enable something:
merkaba:~> btrfstune
usage: btrfstune [options] device
-S value enable/disable seeding
but no manual page here. Seeding is mentioned at:
Seed Device support
It is now possible to create a filesystem to seed other Btrfs filesystems.
The original filesystem and devices are included as a readonly starting
point to the new FS. All modifications go onto different devices and the COW
machinery makes sure the original is unchanged.
http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support
Anyway the documentation of mount options is on:
http://btrfs.ipv5.de/index.php?title=Mount_options
it seems.
There only for "space_cache" it is mentioned that it is permanent. Not for
"inode_cache".
The mount manpage which usually has mount options of various filesystems
does not mention BTRFS yet. I am not sure whether each filesystem should
have an own manpage anyway.
Whatever is used, I would like to have a clear distinction between
permanent and volatile settings. And I think a permanent option is
something which should be set and queryable by a tuning command.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs mount flags
2012-04-13 17:42 ` Duncan
@ 2012-04-14 15:17 ` Kai Krakow
2012-04-15 5:53 ` Duncan
0 siblings, 1 reply; 7+ messages in thread
From: Kai Krakow @ 2012-04-14 15:17 UTC (permalink / raw)
To: linux-btrfs
Duncan <1i5t5.duncan@cox.net> schrieb:
> Kai Krakow posted on Fri, 13 Apr 2012 17:50:45 +0200 as excerpted:
>
>> Is there any documentation about btrfs mount flags wrt:
>> [...]
>
> AFAIK the best documentation is the wiki, which you didn't mention, tho
> you mentioned google. It's also possible that you found the old/outdated
> (because it's read-only after the kernel.org breakin some months ago) wiki
> on btrfs.wiki.kernel.org, but not the current (but possibly temporary)
> one linked below.
>
> So the wiki is where I'd go first. Questions you have after that, ask
> here, and preferably update the wiki with the answers you get, as well.
>
> http://btrfs.ipv5.de/index.php?title=Main_Page
This looks good but I think there's room for improvement. Are there any
mount options which apply to a subvolume only?
And while I see space_cache having the "permanent" annotation in its
description, I see something similar missing for e.g. the inode_cache, ssd,
etc. descriptions. Something that says "not permanent, must be given each
time".
Anyone willing to eloberate on this? I'd offer to contribute this to the
wiki.
Thanks,
Kai
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs mount flags
2012-04-14 15:17 ` Kai Krakow
@ 2012-04-15 5:53 ` Duncan
2012-04-15 10:00 ` Martin Steigerwald
0 siblings, 1 reply; 7+ messages in thread
From: Duncan @ 2012-04-15 5:53 UTC (permalink / raw)
To: linux-btrfs
Kai Krakow posted on Sat, 14 Apr 2012 17:17:30 +0200 as excerpted:
> Duncan <1i5t5.duncan@cox.net> schrieb:
>
>> Kai Krakow posted on Fri, 13 Apr 2012 17:50:45 +0200 as excerpted:
>>
>>> Is there any documentation about btrfs mount flags wrt:
>>> [...]
>>
>> AFAIK the best documentation is the wiki
>> http://btrfs.ipv5.de/index.php?title=Main_Page
>
> This looks good but I think there's room for improvement. Are there any
> mount options which apply to a subvolume only?
Based on comments from the developers I've seen on the list, at present,
pretty much everything is global per-filesystem. (I think ro/rw and
probably the exec/noexec etc style options work per-subvolume mount now,
but not btrfs-feature-specific options. Note that the feature I need
isn't there yet, 3.5/3.6 roadmapped, so I'm not actually running btrfs
myself yet, to check.) There's plans to make much of it, especially
stuff like the compress options, per-mount, and the filesystem has been
designed in general to handle that, but AFAIK the filesystem only has one
instance of the state tracker for that stuff currently, so it's global
per filesystem, not per subvolume, ATM.
> And while I see space_cache having the "permanent" annotation in its
> description, I see something similar missing for e.g. the inode_cache,
> ssd,
> etc. descriptions. Something that says "not permanent, must be given
> each time".
>
> Anyone willing to eloberate on this? I'd offer to contribute this to the
> wiki.
Someone else could confirm, but my understanding is that the space-cache
is special in that it's a newer feature that changes the on-disk format
in a way that isn't fully backward compatible. After it's turned on, an
older kernel can still be used, but the space cache won't be updated, so
it'll be stale when one boots back into a new kernel with the feature
once again. That shouldn't break anything, but it's not ideal, so the
option's there in ordered to let people enable it when they don't
anticipate using older kernels without the feature any longer.
I believe there's a current report of a performance regression due to the
space cache, too, tho it's possible I'm getting this mixed up with the
inode cache. Someone with an ssd is using btrfs as their rootfs, and ran
without the space cache for quite some time. Now the first time the
system's mounted with the space cache, it's supposed to take a bit
longer, but this person is reporting that it's taking MUCH longer, for
EVERY boot, now. The original root read-only mount is fine, but
immediately after the remount read-write, there's a long delay with not a
lot going on, according to the bootchart they were asked to run as a
diagnostic. This guy has something like 60 machines with this problem,
so it's not some random machine acting up, either. I think they've
tracked it to some code that hadn't been updated for the space cache
(corner-case, they didn't expect it would be affected), but I'm not sure
what the status on the patch is. But the expectation is a fix by 3.4
release, some 4-6 weeks or so, from now. Anyway, at least people with
existing btrfs filesystems might want to hold off on enabling that option
for the moment, if they're running the 3.4-rcs, but by 3.4 release, it'll
hopefully be fine.
Most of the others are traditional mount options. The compress options,
for instance, only affect data written (or rewritten due to defrag/
rebalance) while the mount option is on. Existing data, compressed or
not, remains readable either way -- the filesystem automatically
decompresses it on read as necessary, regardless of the state of the
current compression mount options.
--
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs mount flags
2012-04-15 5:53 ` Duncan
@ 2012-04-15 10:00 ` Martin Steigerwald
2012-04-16 3:20 ` Duncan
0 siblings, 1 reply; 7+ messages in thread
From: Martin Steigerwald @ 2012-04-15 10:00 UTC (permalink / raw)
To: linux-btrfs
No cc - instead of whats habit on this list - as you prefer list replies.
Am Sonntag, 15. April 2012 schrieb Duncan:
> I believe there's a current report of a performance regression due to
> the space cache, too, tho it's possible I'm getting this mixed up
> with the inode cache. Someone with an ssd is using btrfs as their
> rootfs, and ran without the space cache for quite some time. Now the
> first time the system's mounted with the space cache, it's supposed to
> take a bit longer, but this person is reporting that it's taking MUCH
> longer, for EVERY boot, now. The original root read-only mount is
> fine, but immediately after the remount read-write, there's a long
> delay with not a lot going on, according to the bootchart they were
> asked to run as a diagnostic. This guy has something like 60 machines
> with this problem, so it's not some random machine acting up,
> either. I think they've tracked it to some code that hadn't been
> updated for the space cache (corner-case, they didn't expect it would
> be affected), but I'm not sure what the status on the patch is. But
> the expectation is a fix by 3.4 release, some 4-6 weeks or so, from
> now. Anyway, at least people with existing btrfs filesystems might
> want to hold off on enabling that option for the moment, if they're
> running the 3.4-rcs, but by 3.4 release, it'll hopefully be fine.
Interesting.
I am running with space_cache and inode_cache for quite some time already,
and did not see issues, but for the moment 3.3 is the newest kernel I use.
When switching forth an back between 3.2/3.3 and earlier kernels I have
seen it being rebuild, which on my ThinkPad T23 where BTRFS generally
seems to be really slow let the boot process crawl. But after it has been
build its fine. While the filesystem is still slower than the XFS I had
there before I believe.
Maybe a fix will be in some rc candidate before 3.4 release.
Maybe an update wiki page could serve as input for additions to mount
Manpage. Or a special btrfs mount options manpage. I would be willing to
help with that as time permits.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs mount flags
2012-04-15 10:00 ` Martin Steigerwald
@ 2012-04-16 3:20 ` Duncan
0 siblings, 0 replies; 7+ messages in thread
From: Duncan @ 2012-04-16 3:20 UTC (permalink / raw)
To: linux-btrfs
Martin Steigerwald posted on Sun, 15 Apr 2012 12:00:31 +0200 as excerpted:
> No cc - instead of whats habit on this list - as you prefer list
> replies.
>
> Am Sonntag, 15. April 2012 schrieb Duncan:
>> I believe there's a current report of a performance regression due to
>> the space cache [but] the expectation is a fix by 3.4 release[.]
>> [A]t least people with existing btrfs filesystems might
>> want to hold off on enabling that option for the moment, if they're
>> running the 3.4-rcs, but by 3.4 release, it'll hopefully be fine.
>
> Maybe a fix will be in some rc candidate before 3.4 release.
I just did a git-pull and see the commit fixing the space-cache bug made
it for 3.4-rc3. So the space-cache mount option should be good to go,
now. Of course btrfs being a development/experimental filesystem,
there's other bugs in process, but that's normal state for current
maturity. This one's fixed, anyway.
> Maybe an update wiki page could serve as input for additions to mount
> Manpage. Or a special btrfs mount options manpage. I would be willing to
> help with that as time permits.
Both would probably be useful.
The mount (8) manpage isn't likely to be reliably current on btrfs for
some time, as btrfs is simply developing too rapidly at this point for
the general-purpose mount docs to keep up. So btrfs-tools shipping a
mount.btrfs manpage or whatever could be quite useful if it's kept
updated, of course the nice thing about manpages being that they're
generally usable without a net connection.
But the wiki page with the mount options should be kept updated as well.
Since it's there already and simply needs upkeep, that'd be the cheaper
alternative for the moment, and an online reference for people to read if
they don't have btrfs-tools installed locally is as useful as a local
manpage reference for those with it local but no net. =:^)
As for updating the wiki... I really should get a login for it so I
can... (I didn't see the usual edit links when not logged in. Not that
I blame whoever's running it. This isn't wikipedia and keeping up with
the spam, etc, would be a serious problem if registration wasn't
required.)
--
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-04-16 3:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-13 15:50 btrfs mount flags Kai Krakow
2012-04-13 17:42 ` Duncan
2012-04-14 15:17 ` Kai Krakow
2012-04-15 5:53 ` Duncan
2012-04-15 10:00 ` Martin Steigerwald
2012-04-16 3:20 ` Duncan
2012-04-13 22:05 ` Martin Steigerwald
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.