Re: Notes on support for multiple devices for a single filesystem

[Kay Sievers]

On Wed, Dec 17, 2008 at 16:08, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Wed, Dec 17, 2008 at 03:50:45PM +0100, Kay Sievers wrote:
>> Sounds all sensible. Btrfs already stores the (possibly incomplete)
>> device tree state in the kernel, which should make things pretty easy
>> for userspace, compared to other already existing subsystems.
>>
>> We could have udev maintain a btrfs volume tree:
>>   /dev/btrfs/
>>   |-- 0cdedd75-2d03-41e6-a1eb-156c0920a021
>>   |   |-- 897fac06-569c-4f45-a0b9-a1f91a9564d4 -> ../../sda10
>>   |   `-- aac20975-b642-4650-b65b-b92ce22616f2 -> ../../sda9
>>   `-- a1ec970a-2463-414e-864c-2eb8ac4e1cf2
>>       |-- 4d1f1fff-4c6b-4b87-8486-36f58abc0610 -> ../../sdb2
>>       `-- e7fe3065-c39f-4295-a099-a89e839ae350 -> ../../sdb1
>>
>> At the same time, by-uuid/ is created:
>>   /dev/disk/by-uuid/
>>   |-- 0cdedd75-2d03-41e6-a1eb-156c0920a021 -> ../../sda10
>>   |-- a1ec970a-2463-414e-864c-2eb8ac4e1cf2 -> ../../sdb2
>>   ...
>
> Well, it's not just btrfs, it's also md, lvm and xfs.  I think the right
> way is to make the single node for the /dev/disk/by-uuid/ just a legacy
> case for potential multiple devices.  E.g. by having
>
> /dev/disk/by-uuid/
>        0cdedd75-2d03-41e6-a1eb-156c0920a021    -> ../../sda10
>        0cdedd75-2d03-41e6-a1eb-156c0920a021.d
>                foo                             -> ../../sda10
>                bar                             -> ../../sda9
>
> where foo nad bar could be uuids if the filesystem / volume manager
> supports it, otherwise just the short name for it.

Sure, we can do something like that. /dev/btrfs/ was just something
for me to start with, and see how the stuff works.

>> For recue and recovery cases, it will still be nice to be able to
>> trigger "scan all devices" code in btrfsctrl (own code or libbklid),
>> but it should be avoided in any normal operation mode.
>
> Again, that's something we should do generically for the whole
> /dev/disk/ tree.   For that we need to merge libvolume_id and libblkid
> so that it has a few related but separate use cases:
>
>  - a lowlevel probe what fs / volume manager / etc is this for
>   the udev callout, mkfs, strip size detection etc

A low-level api will be offered by a future libblkid version in util-linux-ng.

>  - a way to rescan everything, either for non-udev static /dev case
>   or your above recovery scenario

The scan code is part of libblkid, we just need some explicit controls
to enable disable the scanning. It should never be the default, like
it is today.

>  - plus potentially some sort of caching for the non-recovery static
>   /dev case

It's also in libblkid. Today it's pretty useless to cache stuff
indexed by major/minor, but it's there.

> I've long planned to put you and Ted into a room and not let you out
> until we see white smoke :)

A new libblkid already happened at:
  http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=shortlog;h=topic/blkid

Almost all of libvolume_id is already merged into this new version
(only btrfs is missing :)). Udev will switch over to calling blkid
when it's available in a released version of util-linux-ng. I will
just delete the current libvolume_id library after that.

No white smoke, if all works out as planned. :)

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/