Re: [PATCH 23/24] Btrfs: sysfs: support seed devices in the sysfs layout

2015-03-09 Thread Anand Jain



Hi Dave,

 Sorry for the delay I was caught up some issues... (hope I didn't miss 
any of the email).



On 02/13/2015 12:33 PM, David Sterba wrote:

On Thu, Feb 12, 2015 at 02:25:32PM +0800, Anand Jain wrote:

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


While I'm not sure if seeding was originally expected to work on a
multi-device filesystem, it makes sense to me. But what I don't
understand here is the concept of 'nesting'.

Let's say we have device A, B and C, and a * denotes a seeding device.
Then we can start with a populated filesystem on device A.

Then mark it seeding, A*, all fine.

Add device B to A*, all writes are captured by B, fine.


yes. in this context B is called sprout (of A).


Now, we make B seeding.

Mounting the filesystem from A* should not IMO see any device B* as all
changes were stored there, namely the superblock of A* is kept intact.



Mouting from B* should see both A* and B*. Here it may resemble some
nesting or chaining, if that's what you mean.



(Adding a device C to A*, B* would mean that just all writes are captured
by C, ie.  no difference compared to the respective situation for A*, B,
so I can stop the example here.)


yes. you got that right.

In the same context there is this bug:
  search email for the sub: replace seed/sprout hangs (regression ?)


I'm thinking about a representation of the possible relations between
the devices. Seems that the seeding hierarchy for one filesystem is
always linear, so it's ok to represent it by the filesystem UUID chain.



/sys/fs/btrfs/UUID1/UUID2/UUID3


This been(being) done. I will send out the patch RFC for your kind 
integration.



What I still find unsatisfying is lack of any explicit naming attached
to the UUIDs. As we can use lots of types of UUID, saying that if it
looks like an uuid if the main filesystem directory in sysfs, then it's
the seeding filesystem is not the best we can come up with.

I don't have a final idea, but at least

/sys/fs/btrfs/UUID1/seeding/UUID2/seeding/UUID3

would look more friendly to the user and also more accssible to
scripting. We coud possibly add other files/dirs to the inserted
directory.


in the above 'seeding' kobject dir is redundant, since there won't be a 
fsid under a fsid unless its a seed. And there would be a 'seeding' 
attribute to tell is its seeding.




A sidenote: the nesting forms a tree structure so it's possible to do a
snapshotting on the filesystem level, very similar to what the LVM
snapshots do, but here we have to provide a new device manually to
capture the new writes and make sure that all the devices do not
disappear.




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


Re: [PATCH 23/24] Btrfs: sysfs: support seed devices in the sysfs layout

2015-02-17 Thread Anand Jain


[guihc.f...@cn.fujitsu.com
 bounced removing the email id from the cc-list].

Dave,

here is the patch list for Oct.
  https://patchwork.kernel.org/project/linux-btrfs/list/?page=7
v2 isn't there. I am confused.

Anyway if btrfs-progs integration-20150213
contained V2. I am on it now. And I still see the problem.

--
btrfs fi show -- on a nested seed fs
warning devid 1 not found already  ---
warning devid 2 not found already  ---
bytenr mismatch, want=4194304, have=0 
Label: none  uuid: fce49239-b392-4e4d-b775-57dca7f2426b
Total devices 1 FS bytes used 28.00KiB
devid1 size 967.86MiB used 12.00MiB path /dev/sdb

Label: none  uuid: bccc7c86-82ff-4f2c-805a-4d384642f5e6
Total devices 2 FS bytes used 92.00KiB
devid1 size 967.86MiB used 8.00MiB path /dev/sdb
devid2 size 967.87MiB used 144.00MiB path /dev/sdc

Label: none  uuid: 6ea26ac0-b4e9-4a56-9079-67d25a57ac27
Total devices 3 FS bytes used 156.00KiB
devid3 size 1.52GiB used 224.00MiB path /dev/sdd
*** Some devices missing

btrfs-progs v3.19-rc2-68-gd4bf1cc
--

Can you pls revert this patch for now ?


Thanks, Anand



On 02/14/2015 01:51 AM, David Sterba wrote:

On Thu, Feb 12, 2015 at 02:25:32PM +0800, Anand Jain wrote:

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-btrfsm=141102300324251w=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)


The fixed version was [PATCH v2 3/3] btrfs-progs: fix device missing of
btrfs fi show with seed devices

http://article.gmane.org/gmane.comp.file-systems.btrfs/39186/

and that's what I have merged.
--
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


Re: [PATCH 23/24] Btrfs: sysfs: support seed devices in the sysfs layout

2015-02-13 Thread David Sterba
On Thu, Feb 12, 2015 at 02:25:32PM +0800, Anand Jain wrote:
 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-btrfsm=141102300324251w=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)

The fixed version was [PATCH v2 3/3] btrfs-progs: fix device missing of
btrfs fi show with seed devices

http://article.gmane.org/gmane.comp.file-systems.btrfs/39186/

and that's what I have merged.
--
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


Re: [PATCH 23/24] Btrfs: sysfs: support seed devices in the sysfs layout

2015-02-13 Thread David Sterba
On Thu, Feb 12, 2015 at 02:25:32PM +0800, Anand Jain wrote:
 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

While I'm not sure if seeding was originally expected to work on a
multi-device filesystem, it makes sense to me. But what I don't
understand here is the concept of 'nesting'.

Let's say we have device A, B and C, and a * denotes a seeding device.
Then we can start with a populated filesystem on device A.

Then mark it seeding, A*, all fine.

Add device B to A*, all writes are captured by B, fine.

Now, we make B seeding.

Mounting the filesystem from A* should not IMO see any device B* as all
changes were stored there, namely the superblock of A* is kept intact.

Mouting from B* should see both A* and B*. Here it may resemble some
nesting or chaining, if that's what you mean.

(Adding a device C to A*, B* would mean that just all writes are captured
by C, ie.  no difference compared to the respective situation for A*, B,
so I can stop the example here.)

I'm thinking about a representation of the possible relations between
the devices. Seems that the seeding hierarchy for one filesystem is
always linear, so it's ok to represent it by the filesystem UUID chain.

/sys/fs/btrfs/UUID1/UUID2/UUID3

What I still find unsatisfying is lack of any explicit naming attached
to the UUIDs. As we can use lots of types of UUID, saying that if it
looks like an uuid if the main filesystem directory in sysfs, then it's
the seeding filesystem is not the best we can come up with.

I don't have a final idea, but at least

/sys/fs/btrfs/UUID1/seeding/UUID2/seeding/UUID3

would look more friendly to the user and also more accssible to
scripting. We coud possibly add other files/dirs to the inserted
directory.


A sidenote: the nesting forms a tree structure so it's possible to do a
snapshotting on the filesystem level, very similar to what the LVM
snapshots do, but here we have to provide a new device manually to
capture the new writes and make sure that all the devices do not
disappear.
--
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


Re: [PATCH 23/24] Btrfs: sysfs: support seed devices in the sysfs layout

2015-02-11 Thread David Sterba
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?

 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.

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.

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.
--
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


Re: [PATCH 23/24] Btrfs: sysfs: support seed devices in the sysfs layout

2015-02-11 Thread Anand Jain


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-btrfsm=141102300324251w=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


[PATCH 23/24] Btrfs: sysfs: support seed devices in the sysfs layout

2015-02-08 Thread Anand Jain
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.

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
sdf
/sys/fs/btrfs/8c2772d4-6951-43c3-89b6-3ab3c70a13f8/devices

Signed-off-by: Anand Jain anand.j...@oracle.com
---
 fs/btrfs/dev-replace.c |  4 +--
 fs/btrfs/disk-io.c |  4 +--
 fs/btrfs/sysfs.c   | 66 +++---
 fs/btrfs/sysfs.h   |  8 +++---
 fs/btrfs/volumes.c | 40 +-
 5 files changed, 89 insertions(+), 33 deletions(-)

diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 124b60f..e72b986 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -592,8 +592,8 @@ static int btrfs_dev_replace_finishing(struct btrfs_fs_info 
*fs_info,
mutex_unlock(uuid_mutex);
 
/* replace the sysfs entry */
-   btrfs_kobj_rm_device(fs_info-fs_devices, src_device);
-   btrfs_kobj_add_device(fs_info-fs_devices, tgt_device);
+   btrfs_kobj_rm_device(fs_info-fs_devices, src_device, 0);
+   btrfs_kobj_add_device(fs_info-fs_devices, tgt_device, 0);
btrfs_rm_dev_replace_free_srcdev(fs_info, src_device);
 
/* write back the superblocks */
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 4b7f3b8..77372af 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2785,13 +2785,13 @@ retry_root_backup:
 
btrfs_close_extra_devices(fs_info, fs_devices, 1);
 
-   ret = btrfs_sysfs_add_fsid(fs_devices, NULL);
+   ret = btrfs_sysfs_add_fsid(fs_devices, NULL, 1);
if (ret) {
pr_err(BTRFS: failed to init sysfs fsid interface: %d\n, ret);
goto fail_block_groups;
}
 
-   ret = btrfs_sysfs_add_device(fs_devices);
+   ret = btrfs_sysfs_add_device(fs_devices, 1);
if (ret) {
pr_err(BTRFS: failed to init sysfs device interface: %d\n, 
ret);
goto fail_fsdev_sysfs;
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index d89bf4d..f8358d2 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -517,15 +517,20 @@ static int addrm_unknown_feature_attrs(struct 
btrfs_fs_info *fs_info, bool add)
 
 static void __btrfs_sysfs_remove_fsid(struct btrfs_fs_devices *fs_devs)
 {
+   if (fs_devs-seed)
+   __btrfs_sysfs_remove_fsid(fs_devs-seed);
+
if (fs_devs-device_dir_kobj) {
kobject_del(fs_devs-device_dir_kobj);
kobject_put(fs_devs-device_dir_kobj);
fs_devs-device_dir_kobj = NULL;
}
 
-   kobject_del(fs_devs-super_kobj);
-   kobject_put(fs_devs-super_kobj);
-   wait_for_completion(fs_devs-kobj_unregister);
+   if (fs_devs-super_kobj.state_initialized) {
+   kobject_del(fs_devs-super_kobj);
+   kobject_put(fs_devs-super_kobj);
+   wait_for_completion(fs_devs-kobj_unregister);
+   }
 }
 
 /* when fs_devs is NULL it will remove all fsid kobject */
@@ -555,7 +560,7 @@ void btrfs_sysfs_remove_one(struct btrfs_fs_info *fs_info)
addrm_unknown_feature_attrs(fs_info, false);
sysfs_remove_group(fs_info-fs_devices-super_kobj, 
btrfs_feature_attr_group);
sysfs_remove_files(fs_info-fs_devices-super_kobj, btrfs_attrs);
-   btrfs_kobj_rm_device(fs_info-fs_devices, NULL);
+   btrfs_kobj_rm_device(fs_info-fs_devices, NULL, 1);
 }
 
 const char * const btrfs_feature_set_names[3] = {
@@ -636,7 +641,7 @@ static void init_feature_attrs(void)
 /* when one_device is NULL, it removes all device links */
 
 int btrfs_kobj_rm_device(struct btrfs_fs_devices *fs_devices,
-   struct btrfs_device *one_device)
+   struct btrfs_device *one_device, int follow_seed)
 {
struct hd_struct *disk;
struct kobject *disk_kobj;
@@ -666,27 +671,39 @@ int btrfs_kobj_rm_device(struct btrfs_fs_devices 
*fs_devices,
disk_kobj-name);
}
 
+   if (follow_seed  fs_devices-seed)
+   btrfs_kobj_rm_device(fs_devices-seed, NULL, follow_seed);
+
return 0;
 }
 
-int btrfs_sysfs_add_device(struct btrfs_fs_devices *fs_devs)
+int btrfs_sysfs_add_device(struct btrfs_fs_devices *fs_devs, int follow_seed)
 {
-   if (!fs_devs-device_dir_kobj)
-