Thanks for commenting. more below.
On 02/12/2015 02:52 AM, David Sterba wrote:
On Mon, Feb 09, 2015 at 07:56:24AM +0800, Anand Jain wrote:
This adds an enhancement to show the seed fsid and devices.
The way sprouting handles fs_devices:
clone seed fs_devices and add to the fs_uuids
mem copy seed fs_devices and assign to fs_devices->seed (move dev_list)
evacuate seed fs_devices contents to hold sprout fs devices contents
So to be inline with this fs_devices changes during seeding,
represent seed fsid under the sprout fsid, this is achieved
by using the kobject_move()
eg: showing two levels of seeding.
That's new to me, how does nested seeding work?
I called below operation as nested seeding:
mark a sprout as seed, mount it, add a new sprout to it.
eg:
mkfs.btrfs /dev/sdz
btrfstune -S 1 /dev/sdz
mount /dev/sdz /btrfs
btrfs dev add /dev/sdy /btrfs
umount /btrfs
btrfstune -S 1 /dev/sdy
mount /dev/sdy /btrfs
btrfs dev add /dev/sdx /btrfs
(Its bit complicated during seeding, as fs_devices and device move
around. /proc/fs/btrfs/devlist helped to understand. its in the ML)
{
Since we are on this topic: btrfs-progs shouldn't have had this patch:
git log -p 2513077
-------------------------
commit 2513077f2f830b4bc83d528bfb6979eb461918bd
Author: Gui Hecheng <guihc.f...@cn.fujitsu.com>
Date: Mon Oct 6 18:16:46 2014 +0800
btrfs-progs: fix device missing of btrfs fi show with seed devices
-------------------------
it doesn't work with nested seed as I commented
http://marc.info/?l=linux-btrfs&m=141102300324251&w=2
-------------------------
btrfs fi show -d
warning devid 1 not found already
warning devid 2 not found already
Check tree block failed, want=29425664, have=0
read block failed check_tree_block
Couldn't setup csum tree
Check tree block failed, want=29360128, have=0
read block failed check_tree_block
-------------------------
I haven't see next version of this patch from Gui. (Gui ?, copied)
}
find /sys/fs/btrfs/ -type d -name devices -exec ls {} \; -print
sde
/sys/fs/btrfs/8c2772d4-6951-43c3-89b6-3ab3c70a13f8/f7ef2904-ce89-4421-bfb0-49fd999e9a0b/devices
sdd
/sys/fs/btrfs/8c2772d4-6951-43c3-89b6-3ab3c70a13f8/f7ef2904-ce89-4421-bfb0-49fd999e9a0b/53ac3265-0c34-4afd-9453-cc0d1a07be64/devices
The plain uuid is IMHO not the best naming convention, although it's
acceptable in the global list in /sys/fs/btrfs/* I'd rather avoid it if
it's mixed with other files.
just to clarify, the above aren't uuid, they are fsid rather, sorry I
didn't mention.
sde
/sys/fs/btrfs/sprout-fsid/seed-fsid/devices
sdd
/sys/fs/btrfs/sprout-fsid/seed-fsid/2nd-level-seed-fsid/devices
In any case, as in previous RFC patch
[PATCH RFC] btrfs: add sysfs layout to show volume info
uuid will be there, the reasons are first,
btrfs kernel the device uniqueness is determined by fsid-uuid-devid
combination (which means if _any one_ of these is different its going to
create a new struct btrfs_device), so its easy to be inline with that.
name abstraction links on top of it can be created as well.
next,
we originally have device name link under /sys/fs/btrfs/fsid/device.
Since it made first, I doubt if we could alter that to a kobject dir
instead of link?. Some script might be using it. So I am planning to put
uuid under /sys/fs/btrfs/fsid/device to contain info about the device.
as shown in the RFC patch above.
Would it be enough to print all relevant seeding information into a
single file? If the "UUID" directoreis do not contain anything else,
that would be IMHO best.
Hmm nope it will contain more info.
Do the seeding fsids exist on their own in /sys/sf/btrfs? I haven't
tested the patchset so I'd probably find that out myself.
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
