Hello, I''ve noticed one mounts btrfs filesystems by device name (eg /dev/sda1), even in a multi-device filesystem. I see there''s a uuid for the filesystem in btrfs_super_block, so this is safe to do even if the devices change names in the future, but it''s somewhat sub-optimal in that one''s fstab won''t necessarily continue to work. Even if the devices themselves have uuid''s that get used in fstab, a given device could just as easily go away in the future. I also see the standard Linux mount command is used here, and it''s clearly designed around the assumption of a 1:1 relationship between block devices and filesystems, with multi-device stuff happening at another layer. One assumes the btrfs code in the kernel just grabs the uuid from that device and uses it to assemble the filesystem from whatever devices are also members. My question is: are there plans to support mounting by uuid of the filesystem directly, or by providing something like /dev/btrfs/XXXXX to make the mount command happy? Wherever this has been done in Linux to date (eg filesystems, software RAID, LVMs, etc) it''s almost always been a good thing, it would be a step down to eg worry about what order drives were plugged in. Thanks for any responses. :) Cheers, -Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 07 June 2008, btrfs-devel@arbitraryconstant.com wrote:> Hello, > > I''ve noticed one mounts btrfs filesystems by device name (eg /dev/sda1), > even in a multi-device filesystem. I see there''s a uuid for the filesystem > in btrfs_super_block, so this is safe to do even if the devices change > names in the future, but it''s somewhat sub-optimal in that one''s fstab > won''t necessarily continue to work. Even if the devices themselves have > uuid''s that get used in fstab, a given device could just as easily go away > in the future. > > I also see the standard Linux mount command is used here, and it''s clearly > designed around the assumption of a 1:1 relationship between block devices > and filesystems, with multi-device stuff happening at another layer. One > assumes the btrfs code in the kernel just grabs the uuid from that device > and uses it to assemble the filesystem from whatever devices are also > members. > > My question is: are there plans to support mounting by uuid of the > filesystem directly, or by providing something like /dev/btrfs/XXXXX to > make the mount command happy? Wherever this has been done in Linux to date > (eg filesystems, software RAID, LVMs, etc) it''s almost always been a good > thing, it would be a step down to eg worry about what order drives were > plugged in. > > Thanks for any responses. :)Btrfs does something similar to LVM for device management, there is a scanning program that finds btrfs volumes and populates a kernel table matching filesystem uuid to devices. So, if /dev/sdb becomes /dev/sdc, btrfs will still do the right thing. Btrfs doesn''t actually store device path names in the FS metadata, so it has no idea that /dev/sdb is part of your FS. It just scans super blocks and is able to mount them wherever it finds them. This means the device you pass to mount is going to move around as the devices move which is kind of awkward. Longer term, it''ll move to a udev helper style setup that puts links into a /dev/btrfs/by-uuid and /dev/btrfs/by-label See the btrfs-show command for an example of how the scanning is done if you''re in a patching mood. It could populate the /dev/btrfs directory directly. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jun 07, 2008 at 05:53:37PM -0600, btrfs-devel@arbitraryconstant.com wrote:> Hello, > > I''ve noticed one mounts btrfs filesystems by device name (eg /dev/sda1), > even in a multi-device filesystem. I see there''s a uuid for the filesystem > in btrfs_super_block, so this is safe to do even if the devices change > names in the future, but it''s somewhat sub-optimal in that one''s fstab > won''t necessarily continue to work. Even if the devices themselves have > uuid''s that get used in fstab, a given device could just as easily go away > in the future.You can mount by uuid, altough not yet a multi-device btrfs setup.> I also see the standard Linux mount command is used here, and it''s clearly > designed around the assumption of a 1:1 relationship between block devices > and filesystems, with multi-device stuff happening at another layer. One > assumes the btrfs code in the kernel just grabs the uuid from that device > and uses it to assemble the filesystem from whatever devices are also > members.It doesn''t even automatically assemble all other devices.> My question is: are there plans to support mounting by uuid of the > filesystem directly, or by providing something like /dev/btrfs/XXXXX to > make the mount command happy? Wherever this has been done in Linux to date > (eg filesystems, software RAID, LVMs, etc) it''s almost always been a good > thing, it would be a step down to eg worry about what order drives were > plugged in.Yes, I plan to work on adding properly designed multiple device support for btrfs and my upcoming similar xfs work. I''ll live in good old mount and libvolume_id. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 9 Jun 2008 02:43:58 -0400 Christoph Hellwig <hch@infradead.org> wrote:> On Sat, Jun 07, 2008 at 05:53:37PM -0600,> Yes, I plan to work on adding properly designed multiple device > support for btrfs and my upcoming similar xfs work. I''ll live in > good old mount and libvolume_id. >I won''t say no to a mount patch either. The only downside is that we''ll need to update it (in mount) as the format goes through changes over the summer. But that is a temporary problem. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all, On Mon, Jun 9, 2008 at 11:06 AM, Chris Mason <chris.mason@oracle.com> wrote:> On Mon, 9 Jun 2008 02:43:58 -0400 > Christoph Hellwig <hch@infradead.org> wrote: > >> On Sat, Jun 07, 2008 at 05:53:37PM -0600, > >> Yes, I plan to work on adding properly designed multiple device >> support for btrfs and my upcoming similar xfs work. I''ll live in >> good old mount and libvolume_id. >> > > I won''t say no to a mount patch either. The only downside is that > we''ll need to update it (in mount) as the format goes through changes > over the summer. But that is a temporary problem.I believe that a multi-volume filesystem should have some kind of human understandable handle/name. Just like a name of a logical volume. For single disks filesystems, the disk name suffices (and reduced the need for such a name/label), but in multi-disk FS there should still be a humane name for that mountpoint or filesystem. So, while any unique identifier would technically be okay, I think that there should be a human undertanble name/label for it. Not just some uid. Does Hellwig work, or any planned feature provide this ? Kind regards, -- Miguel Sousa Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2008-06-09 at 14:45 +0100, Miguel Sousa Filipe wrote:> Hi all, > > On Mon, Jun 9, 2008 at 11:06 AM, Chris Mason <chris.mason@oracle.com> wrote: > > On Mon, 9 Jun 2008 02:43:58 -0400 > > Christoph Hellwig <hch@infradead.org> wrote: > > > >> On Sat, Jun 07, 2008 at 05:53:37PM -0600, > > > >> Yes, I plan to work on adding properly designed multiple device > >> support for btrfs and my upcoming similar xfs work. I''ll live in > >> good old mount and libvolume_id. > >> > > > > I won''t say no to a mount patch either. The only downside is that > > we''ll need to update it (in mount) as the format goes through changes > > over the summer. But that is a temporary problem. > > > I believe that a multi-volume filesystem should have some kind of > human understandable handle/name. > Just like a name of a logical volume. For single disks filesystems, > the disk name suffices (and reduced the need for such a name/label), > but in multi-disk FS there should still be a humane name for that > mountpoint or filesystem. > So, while any unique identifier would technically be okay, I think > that there should be a human undertanble name/label for it. Not just > some uid. > > Does Hellwig work, or any planned feature provide this ?mkfs.btrfs already has a way to set the label of the filesystem. mkfs.btrfs -L label /dev/xxxx btrfs-show will show you the labels of any existing filesystems. In practice, anyone on a san really wants to use uuids. Labels are nice until two people on the same san create a filesystem named system, and then it all gets ugly ;) -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 9, 2008 at 2:52 PM, Chris Mason <chris.mason@oracle.com> wrote:> On Mon, 2008-06-09 at 14:45 +0100, Miguel Sousa Filipe wrote: >> Hi all, >> >> On Mon, Jun 9, 2008 at 11:06 AM, Chris Mason <chris.mason@oracle.com> wrote: >> > On Mon, 9 Jun 2008 02:43:58 -0400 >> > Christoph Hellwig <hch@infradead.org> wrote: >> > >> >> On Sat, Jun 07, 2008 at 05:53:37PM -0600, >> > >> >> Yes, I plan to work on adding properly designed multiple device >> >> support for btrfs and my upcoming similar xfs work. I''ll live in >> >> good old mount and libvolume_id. >> >> >> > >> > I won''t say no to a mount patch either. The only downside is that >> > we''ll need to update it (in mount) as the format goes through changes >> > over the summer. But that is a temporary problem. >> >> >> I believe that a multi-volume filesystem should have some kind of >> human understandable handle/name. >> Just like a name of a logical volume. For single disks filesystems, >> the disk name suffices (and reduced the need for such a name/label), >> but in multi-disk FS there should still be a humane name for that >> mountpoint or filesystem. >> So, while any unique identifier would technically be okay, I think >> that there should be a human undertanble name/label for it. Not just >> some uid. >> >> Does Hellwig work, or any planned feature provide this ? > > mkfs.btrfs already has a way to set the label of the filesystem. > mkfs.btrfs -L label /dev/xxxx > > btrfs-show will show you the labels of any existing filesystems. >Can I mount by label ? something like: # mount /dev/btrfs/label /mountpoint> In practice, anyone on a san really wants to use uuids. Labels are nice > until two people on the same san create a filesystem named system, and > then it all gets ugly ;)It can make sense to use uuids there, (Although that looks to me like a comunication problem).. But replacing a human readable id with a unreadable one will worsen the usability and make it more dificult on a lot of scenarios were uuids aren''t needed. UUID doesn''t solve a very common requisite: having a human readable name for a volume/mountpoint/filesystem. Kind regards, -- Miguel Sousa Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html