В Sun, 13 Oct 2013 08:56:18 +0400
Andrey Borzenkov <arvidjaar(a)gmail.com> пишет:
В Mon, 23 Sep 2013 15:37:21 -0400
Jeff Mahoney <jeffm(a)suse.com> пишет:
On 9/23/13 2:44 PM, Cristian Rodríguez wrote:
El 23/09/13 12:46, Jeff Mahoney escribió:
On 9/22/13 8:15 PM, Cristian Rodríguez wrote:
> with current kernel:head (kernel-desktop-3.11.1-5.1.g50dfbd0) I am
> getting a flood of this warnings..
Well that's certainly strange. This is from the new sysfs code that
creates a per-fs directory to publish the enabled features on a
particular file system. The message in $SUBJECT seems to indicate that
your file system has a zeroed out fsid, which AFAIK, really shouldn't
hrmmm.. the btrfs command line tool said that both of my filesystems
have a non-zeroed fsid..
Ah. Yep. This was a bug in the error path for btrfs_mount -- it would
attempt to create the sysfs dir even if btrfs_fill_super had failed.
I've pushed a fix for it just now.
I still get it on RC1 (3.11.3-1.1). Was fix supposed to be included
I get it every time when I try to concurrently mount more than one
Looking at it, I'm not sure how it is supposed to work (if it is
supposed to work at all). Apparently btrfs attempts to
create /sys/fs/btrfs/$UUID directory for every mounted subvolume, where
$UUID is the same. This of course cannot work. Second attempt now
creates 00000... and third and subsequent attempts simply fail because
0000... already exists.
As far as I can tell, the only information in this directory is
filesystem features. So I see to possibilities
- if filesystem features are per FS (and not per active mount) - there
should be just exactly one directory for any number of active mounts.
- if there is some information that may differ between active mounts -
directory name has to be extended with subvolume ID, something