[PATCH 05/12] Btrfc: sysfs: fix, check if device_dir_kobj is init before destroy

Since the failure code in the btrfs_sysfs_add_one() can call btrfs_sysfs_remove_one() even before device_dir_kobj has been created we need to check if its null. Signed-off-by: Anand Jain anand.j...@oracle.com --- fs/btrfs/sysfs.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-)

[PATCH 06/12] Btrfs: sysfs: reorder the kobject creations

As of now the order in which the kobjects are created at btrfs_sysfs_add_one() is.. fsid features unknown features (dynamic features) devices. Since we would move fsid and device kobject to fs_devices from fs_info structure, this patch will reorder in which the kobjects are created as below.

[PATCH 08/12] Btrfs: sysfs: introduce function btrfs_sysfs_add_fsid() to create sysfs fsid

We need it in a seperate function so that it can be called from the device discovery thread as well. Signed-off-by: Anand Jain anand.j...@oracle.com --- fs/btrfs/sysfs.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c index

[PATCH 12/12] Btrfs: sysfs: add pointer to access fs_info from fs_devices

adds fs_info pointer with struct btrfs_fs_devices. Signed-off-by: Anand Jain anand.j...@oracle.com --- fs/btrfs/sysfs.c | 4 fs/btrfs/volumes.h | 1 + 2 files changed, 5 insertions(+) diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c index ac15fbb..4b5bac6 100644 --- a/fs/btrfs/sysfs.c

[PATCH] Btrfs-progs: add regression tests for sysfs contents during btrfs device management

This contains a series of btrfs device operations and at each operation the btrfs sysfs contents are logged. This helps to check if the patch is affecting any of the btrfs sysfs contents. OR This script can be used to test the only the device operations. as of now there are 32 test cases

[PATCH 07/12] Btrfs: sysfs: rename __btrfs_sysfs_remove_one to btrfs_sysfs_remove_fsid

Signed-off-by: Anand Jain anand.j...@oracle.com --- fs/btrfs/sysfs.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c index c3e7f06..c923e8b 100644 --- a/fs/btrfs/sysfs.c +++ b/fs/btrfs/sysfs.c @@ -508,7 +508,7 @@ static int

[PATCH 11/12] Btrfs: sysfs: move super_kobj and device_dir_kobj from fs_info to btrfs_fs_devices

This patch will provide a framework and help to create attributes from the structure btrfs_fs_devices which are available even before fs_info is created. So by moving the parent kobject super_kobj from fs_info to btrfs_fs_devices, it will help to create attributes from the btrfs_fs_devices as

[PATCH 03/12] Btrfs: sysfs: fix, undo sysfs device links

Theoritically need to remove the device links attributes, but since its entire device kobject was removed, so there wasn't any issue of about it. Just do it nicely. Signed-off-by: Anand Jain anand.j...@oracle.com --- fs/btrfs/sysfs.c | 17 + 1 file changed, 17 insertions(+)

[PATCH 09/12] Btrfs: sysfs: let default_attrs be separate from the kset

As of now btrfs_attrs are provided using the default_attrs through the kset. Separate them and create the default_attrs using the sysfs_create_files instead. By doing this we will have the flexibility that device discovery thread could create fsid kobject. Signed-off-by: Anand Jain

[PATCH 10/12] Btrfs: sysfs: separate device kobject and its attribute creation

Separate device kobject and its attribute creation so that device kobject can be created from the device discovery thread. Signed-off-by: Anand Jain anand.j...@oracle.com --- fs/btrfs/sysfs.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git

[PATCH 04/12] Btrfs: sysfs: fix, kobject pointer clean up needed after kobject release

The sysfs clean up self test like in the below code fails, since fs_info-device_dir_kobject still points to its stale kobject. Reseting this pointer will help to fix this. open_ctree() { ret = btrfs_sysfs_add_one(fs_info); :: + btrfs_sysfs_remove_one(fs_info); + ret =

[PATCH 01/12] Btrfs: sysfs: fix, btrfs_release_super_kobj() should to clean up the kobject data

The following test case fails indicating that, thread tried to init an initialized object. kernel: [232104.016513] kobject (880006c1c980): tried to init an initialized object, something is seriously wrong. btrfs_sysfs_remove_one() self test code: open_tree() { :: ret =

[PATCH 00/12] provide frame work so that sysfs attributs from the fs_devices can be added

This patch set will provide a framework and help to create attributes from the structure btrfs_fs_devices which are available even before fs_info is created. So by moving the parent kobject super_kobj from fs_info to btrfs_fs_devices, it will help to create attributes from the btrfs_fs_devices as

[PATCH 02/12] Btrfs: sysfs: fix, fs_info kobject_unregister has init_completion() twice

kobject_unregister is to handle the release of the kobject, its completion init is being called in btrfs_sysfs_add_one(), so we don't have to do the same in the open_ctree() again. Signed-off-by: Anand Jain anand.j...@oracle.com --- fs/btrfs/disk-io.c | 1 - 1 file changed, 1 deletion(-) diff

security.capability xattr missing after btrfs send/receive

I found that the security.capability xattr gets lost when cloning a subvolume via btrfs send | btrfs receive. This is easy to reproduce (currently on 3.19.0-rc6, x86_64, with btrfs-progs 3.18.1): Have two btrfs file systems, /fs1 and /fs2. # btrfs sub create /fs1/test # touch /fs1/test/foo #

Re: security.capability xattr missing after btrfs send/receive

El dom, 01-02-2015 a las 13:13 +0100, Jan Andres escribió: I found that the security.capability xattr gets lost when cloning a subvolume via btrfs send | btrfs receive. This is easy to reproduce (currently on 3.19.0-rc6, x86_64, with btrfs-progs 3.18.1): Have two btrfs file systems, /fs1 and

Re: security.capability xattr missing after btrfs send/receive

Looks like security.capabilities also has tripped up tar. https://bugzilla.redhat.com/show_bug.cgi?id=771927 There's a suggestion that security.capabilities are non standard attributes? Also, comment 28 is interesting. Anyway it seems a big messy to support them in any case. -- To unsubscribe

How to fix uncorrectable errors

  About a week ago my machine started reporting the following after scrubbing the btrfs filesystem which I do regularly: scrub status for f74d1ed9-e591-4cbd-8b56-cda5c2f40285 scrub device /dev/sda (id 1) history scrub started at Wed Jan 28 01:00:02 2015 and finished after 48737 seconds total

Re: How to fix uncorrectable errors

I think more info is needed. What kernel and btrfs-progs versions have been tried? What hardware? What is btrfs fi show and fi df mp? What files, are there snapshots, etc? Is there any pattern to the two cases, like the same types of files? And what are the kernel messages for the above scrub (the

re: btrfs: qgroup: account shared subtrees during snapshot delete

Hello Mark Fasheh, The patch 1152651a0817: btrfs: qgroup: account shared subtrees during snapshot delete from Jul 17, 2014, leads to the following static checker warning: fs/btrfs/extent-tree.c:7642 account_shared_subtree() error: off-by-one overflow 'path-nodes' size 8. index

[PATCH] Btrfs: fix find_free_dev_extent() malfunction in case device tree has hole

If device tree has hole, find_free_dev_extent() cannot find available address properly. The example below, has one BIG hole in device tree, and can only allocate just one chunk in a transaction. item 9 key (1 DEV_EXTENT 273841913856) itemoff 15811 itemsize 48 dev extent chunk_tree 3

Re: __might_sleep() warnings on v3.19-rc6

(high-jacking the thread a bit... I don't have the patch that I want to reply to still in my mail box: the subject still matches...) I just got a might-sleep warning in my own testing. This was introduced by commit e22b886a8a43b147e1994a9f970f678fc0df2033 Author: Peter Zijlstra

Re: __might_sleep() warnings on v3.19-rc6

On Sun, 1 Feb 2015 21:08:12 -0800 Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Feb 1, 2015 at 3:03 PM, NeilBrown ne...@suse.de wrote: I guess I could __set_current_state(TASK_RUNNING); somewhere to defeat the warning, and add a comment explaining why. Would that

Unclean shutdown, BTRFS will not mount after - what things to try in what order?

We have a Ubuntu 14.10 server that has a BTRFS root filesystem. There was a power outage, and the server will not boot afterwards. We went into rescue mode, and / didn't mount there, in the /var/log/syslog we see: BTRFS: read error corrected: ino 1 of 398856193 (dev /dev/sda1 sector 795400)