[PATCH 4/4] Btrfs: rollback btrfs_device fields on umount

2013-08-12 Thread Ilya Dryomov 
It turns out we don't properly rollback in-core btrfs_device state on
umount.  We zero out -bdev, -in_fs_metadata and that's about it.  In
particular, we don't zero out -generation, and this can lead to us
refusing a mount -- a non-NULL fs_devices-latest_bdev is essential, but
btrfs_close_extra_devices will happily assign NULL to -latest_bdev if
the first device on the dev_list happens to be missing and consequently
has no bdev attached.  This happens because since commit a6b0d5c8
btrfs_close_extra_devices adjusts -latest_bdev, and in doing that,
relies on the -generation.  Fix this, and possibly other problems, by
zeroing out everything except for what device_list_add sets, so that a
mount right after insmod and 'btrfs dev scan' is no different from any
later mount in this respect.

Signed-off-by: Ilya Dryomov idryo...@gmail.com
---
 fs/btrfs/volumes.c |   15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index af17b17..2f6bc12 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -673,22 +673,19 @@ static int __btrfs_close_devices(struct btrfs_fs_devices 
*fs_devices)
if (device-can_discard)
fs_devices-num_can_discard--;
 
-   new_device = kmalloc(sizeof(*new_device), GFP_NOFS);
-   BUG_ON(!new_device); /* -ENOMEM */
-   memcpy(new_device, device, sizeof(*new_device));
+   new_device = btrfs_alloc_device(NULL, device-devid,
+   device-uuid);
+   BUG_ON(IS_ERR(new_device)); /* -ENOMEM */
 
/* Safe because we are under uuid_mutex */
if (device-name) {
name = rcu_string_strdup(device-name-str, GFP_NOFS);
-   BUG_ON(device-name  !name); /* -ENOMEM */
+   BUG_ON(!name); /* -ENOMEM */
rcu_assign_pointer(new_device-name, name);
}
-   new_device-bdev = NULL;
-   new_device-writeable = 0;
-   new_device-in_fs_metadata = 0;
-   new_device-can_discard = 0;
-   spin_lock_init(new_device-io_lock);
+
list_replace_rcu(device-dev_list, new_device-dev_list);
+   new_device-fs_devices = device-fs_devices;
 
call_rcu(device-rcu, free_device);
}
-- 
1.7.10.4

--
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 2/4] Btrfs: add btrfs_alloc_device and switch to it

2013-08-12 Thread Ilya Dryomov 
Currently btrfs_device is allocated ad-hoc in a few different places,
and as a result not all fields are initialized properly.  In particular,
readahead state is only initialized in device_list_add (at scan time),
and not in btrfs_init_new_device (when the new device is added with
'btrfs dev add').  Fix this by adding an allocation helper and switch
everybody but __btrfs_close_devices to it.  (__btrfs_close_devices is
dealt with in a later commit.)

Signed-off-by: Ilya Dryomov idryo...@gmail.com
---
 fs/btrfs/volumes.c |  150 
 fs/btrfs/volumes.h |3 ++
 2 files changed, 96 insertions(+), 57 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index ae1bcb0..fe52704 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -101,6 +101,27 @@ void btrfs_cleanup_fs_uuids(void)
}
 }
 
+static struct btrfs_device *__alloc_device(void)
+{
+   struct btrfs_device *dev;
+
+   dev = kzalloc(sizeof(*dev), GFP_NOFS);
+   if (!dev)
+   return ERR_PTR(-ENOMEM);
+
+   INIT_LIST_HEAD(dev-dev_list);
+   INIT_LIST_HEAD(dev-dev_alloc_list);
+
+   spin_lock_init(dev-io_lock);
+
+   spin_lock_init(dev-reada_lock);
+   atomic_set(dev-reada_in_flight, 0);
+   INIT_RADIX_TREE(dev-reada_zones, GFP_NOFS  ~__GFP_WAIT);
+   INIT_RADIX_TREE(dev-reada_extents, GFP_NOFS  ~__GFP_WAIT);
+
+   return dev;
+}
+
 static noinline struct btrfs_device *__find_device(struct list_head *head,
   u64 devid, u8 *uuid)
 {
@@ -414,17 +435,12 @@ static noinline int device_list_add(const char *path,
if (fs_devices-opened)
return -EBUSY;
 
-   device = kzalloc(sizeof(*device), GFP_NOFS);
-   if (!device) {
+   device = btrfs_alloc_device(NULL, devid,
+   disk_super-dev_item.uuid);
+   if (IS_ERR(device)) {
/* we can safely leave the fs_devices entry around */
-   return -ENOMEM;
+   return PTR_ERR(device);
}
-   device-devid = devid;
-   device-dev_stats_valid = 0;
-   device-work.func = pending_bios_fn;
-   memcpy(device-uuid, disk_super-dev_item.uuid,
-  BTRFS_UUID_SIZE);
-   spin_lock_init(device-io_lock);
 
name = rcu_string_strdup(path, GFP_NOFS);
if (!name) {
@@ -432,15 +448,6 @@ static noinline int device_list_add(const char *path,
return -ENOMEM;
}
rcu_assign_pointer(device-name, name);
-   INIT_LIST_HEAD(device-dev_alloc_list);
-
-   /* init readahead state */
-   spin_lock_init(device-reada_lock);
-   device-reada_curr_zone = NULL;
-   atomic_set(device-reada_in_flight, 0);
-   device-reada_next = 0;
-   INIT_RADIX_TREE(device-reada_zones, GFP_NOFS  ~__GFP_WAIT);
-   INIT_RADIX_TREE(device-reada_extents, GFP_NOFS  ~__GFP_WAIT);
 
mutex_lock(fs_devices-device_list_mutex);
list_add_rcu(device-dev_list, fs_devices-devices);
@@ -491,8 +498,9 @@ static struct btrfs_fs_devices *clone_fs_devices(struct 
btrfs_fs_devices *orig)
list_for_each_entry(orig_dev, orig-devices, dev_list) {
struct rcu_string *name;
 
-   device = kzalloc(sizeof(*device), GFP_NOFS);
-   if (!device)
+   device = btrfs_alloc_device(NULL, orig_dev-devid,
+   orig_dev-uuid);
+   if (IS_ERR(device))
goto error;
 
/*
@@ -506,13 +514,6 @@ static struct btrfs_fs_devices *clone_fs_devices(struct 
btrfs_fs_devices *orig)
}
rcu_assign_pointer(device-name, name);
 
-   device-devid = orig_dev-devid;
-   device-work.func = pending_bios_fn;
-   memcpy(device-uuid, orig_dev-uuid, sizeof(device-uuid));
-   spin_lock_init(device-io_lock);
-   INIT_LIST_HEAD(device-dev_list);
-   INIT_LIST_HEAD(device-dev_alloc_list);
-
list_add(device-dev_list, fs_devices-devices);
device-fs_devices = fs_devices;
fs_devices-num_devices++;
@@ -1956,10 +1957,10 @@ int btrfs_init_new_device(struct btrfs_root *root, char 
*device_path)
}
mutex_unlock(root-fs_info-fs_devices-device_list_mutex);
 
-   device = kzalloc(sizeof(*device), GFP_NOFS);
-   if (!device) {
+   device = btrfs_alloc_device(root-fs_info, NULL, NULL);
+   if (IS_ERR(device)) {
/* we can safely leave the fs_devices entry around */
-   ret = -ENOMEM;
+   ret = PTR_ERR(device);
goto

[PATCH 3/4] Btrfs: add alloc_fs_devices and switch to it

2013-08-12 Thread Ilya Dryomov 
In the spirit of btrfs_alloc_device, add a helper for allocating and
doing some common initialization of btrfs_fs_devices struct.

Signed-off-by: Ilya Dryomov idryo...@gmail.com
---
 fs/btrfs/volumes.c |   71 +++-
 1 file changed, 53 insertions(+), 18 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index fe52704..af17b17 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -62,6 +62,48 @@ static void unlock_chunks(struct btrfs_root *root)
mutex_unlock(root-fs_info-chunk_mutex);
 }
 
+static struct btrfs_fs_devices *__alloc_fs_devices(void)
+{
+   struct btrfs_fs_devices *fs_devs;
+
+   fs_devs = kzalloc(sizeof(*fs_devs), GFP_NOFS);
+   if (!fs_devs)
+   return ERR_PTR(-ENOMEM);
+
+   mutex_init(fs_devs-device_list_mutex);
+
+   INIT_LIST_HEAD(fs_devs-devices);
+   INIT_LIST_HEAD(fs_devs-alloc_list);
+   INIT_LIST_HEAD(fs_devs-list);
+
+   return fs_devs;
+}
+
+/**
+ * alloc_fs_devices - allocate struct btrfs_fs_devices
+ * @fsid:  a pointer to UUID for this FS.  If NULL a new UUID is
+ * generated.
+ *
+ * Return: a pointer to a new struct btrfs_fs_devices on success;
+ * ERR_PTR() on error.  Returned struct is not linked onto any lists and
+ * can be destroyed with kfree() right away.
+ */
+static struct btrfs_fs_devices *alloc_fs_devices(const u8 *fsid)
+{
+   struct btrfs_fs_devices *fs_devs;
+
+   fs_devs = __alloc_fs_devices();
+   if (IS_ERR(fs_devs))
+   return fs_devs;
+
+   if (fsid)
+   memcpy(fs_devs-fsid, fsid, BTRFS_FSID_SIZE);
+   else
+   generate_random_uuid(fs_devs-fsid);
+
+   return fs_devs;
+}
+
 static void free_fs_devices(struct btrfs_fs_devices *fs_devices)
 {
struct btrfs_device *device;
@@ -416,16 +458,14 @@ static noinline int device_list_add(const char *path,
 
fs_devices = find_fsid(disk_super-fsid);
if (!fs_devices) {
-   fs_devices = kzalloc(sizeof(*fs_devices), GFP_NOFS);
-   if (!fs_devices)
-   return -ENOMEM;
-   INIT_LIST_HEAD(fs_devices-devices);
-   INIT_LIST_HEAD(fs_devices-alloc_list);
+   fs_devices = alloc_fs_devices(disk_super-fsid);
+   if (IS_ERR(fs_devices))
+   return PTR_ERR(fs_devices);
+
list_add(fs_devices-list, fs_uuids);
-   memcpy(fs_devices-fsid, disk_super-fsid, BTRFS_FSID_SIZE);
fs_devices-latest_devid = devid;
fs_devices-latest_trans = found_transid;
-   mutex_init(fs_devices-device_list_mutex);
+
device = NULL;
} else {
device = __find_device(fs_devices-devices, devid,
@@ -481,18 +521,13 @@ static struct btrfs_fs_devices *clone_fs_devices(struct 
btrfs_fs_devices *orig)
struct btrfs_device *device;
struct btrfs_device *orig_dev;
 
-   fs_devices = kzalloc(sizeof(*fs_devices), GFP_NOFS);
-   if (!fs_devices)
-   return ERR_PTR(-ENOMEM);
+   fs_devices = alloc_fs_devices(orig-fsid);
+   if (IS_ERR(fs_devices))
+   return fs_devices;
 
-   INIT_LIST_HEAD(fs_devices-devices);
-   INIT_LIST_HEAD(fs_devices-alloc_list);
-   INIT_LIST_HEAD(fs_devices-list);
-   mutex_init(fs_devices-device_list_mutex);
fs_devices-latest_devid = orig-latest_devid;
fs_devices-latest_trans = orig-latest_trans;
fs_devices-total_devices = orig-total_devices;
-   memcpy(fs_devices-fsid, orig-fsid, sizeof(fs_devices-fsid));
 
/* We have held the volume lock, it is safe to get the devices. */
list_for_each_entry(orig_dev, orig-devices, dev_list) {
@@ -1794,9 +1829,9 @@ static int btrfs_prepare_sprout(struct btrfs_root *root)
if (!fs_devices-seeding)
return -EINVAL;
 
-   seed_devices = kzalloc(sizeof(*fs_devices), GFP_NOFS);
-   if (!seed_devices)
-   return -ENOMEM;
+   seed_devices = __alloc_fs_devices();
+   if (IS_ERR(seed_devices))
+   return PTR_ERR(seed_devices);
 
old_devices = clone_fs_devices(fs_devices);
if (IS_ERR(old_devices)) {
-- 
1.7.10.4

--
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 0/4] btrfs_device fixes

2013-08-12 Thread Ilya Dryomov 
Hello,

This patch series does two things:

- adds allocation helpers for struct btrfs_device and struct
  btrfs_fs_devices so that all the list_heads, spinlocks, etc are
  properly initialized and the code for that is in one place;

- fixes a bug in the umount sequence, which, under certain conditions,
  can lead to mount failures.

This is on top of 3.11-rc3, but applies cleanly to btrfs-next/master as
of now.  You can pull from:

git://github.com/idryomov/btrfs-unstable.git dev-fixes
 
Thanks,

Ilya


Ilya Dryomov (4):
  Btrfs: find_next_devid: root - fs_info
  Btrfs: add btrfs_alloc_device and switch to it
  Btrfs: add alloc_fs_devices and switch to it
  Btrfs: rollback btrfs_device fields on umount

 fs/btrfs/volumes.c |  250 +---
 fs/btrfs/volumes.h |3 +
 2 files changed, 162 insertions(+), 91 deletions(-)

-- 
1.7.10.4

--
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 1/4] Btrfs: find_next_devid: root - fs_info

2013-08-12 Thread Ilya Dryomov 
find_next_devid() knows which root to search, so it should take an
fs_info instead of an arbitrary root.

Signed-off-by: Ilya Dryomov idryo...@gmail.com
---
 fs/btrfs/volumes.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 78b8717..ae1bcb0 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1307,15 +1307,14 @@ static u64 find_next_chunk(struct btrfs_fs_info 
*fs_info)
return ret;
 }
 
-static noinline int find_next_devid(struct btrfs_root *root, u64 *objectid)
+static noinline int find_next_devid(struct btrfs_fs_info *fs_info,
+   u64 *devid_ret)
 {
int ret;
struct btrfs_key key;
struct btrfs_key found_key;
struct btrfs_path *path;
 
-   root = root-fs_info-chunk_root;
-
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
@@ -1324,20 +1323,21 @@ static noinline int find_next_devid(struct btrfs_root 
*root, u64 *objectid)
key.type = BTRFS_DEV_ITEM_KEY;
key.offset = (u64)-1;
 
-   ret = btrfs_search_slot(NULL, root, key, path, 0, 0);
+   ret = btrfs_search_slot(NULL, fs_info-chunk_root, key, path, 0, 0);
if (ret  0)
goto error;
 
BUG_ON(ret == 0); /* Corruption */
 
-   ret = btrfs_previous_item(root, path, BTRFS_DEV_ITEMS_OBJECTID,
+   ret = btrfs_previous_item(fs_info-chunk_root, path,
+ BTRFS_DEV_ITEMS_OBJECTID,
  BTRFS_DEV_ITEM_KEY);
if (ret) {
-   *objectid = 1;
+   *devid_ret = 1;
} else {
btrfs_item_key_to_cpu(path-nodes[0], found_key,
  path-slots[0]);
-   *objectid = found_key.offset + 1;
+   *devid_ret = found_key.offset + 1;
}
ret = 0;
 error:
@@ -1971,7 +1971,7 @@ int btrfs_init_new_device(struct btrfs_root *root, char 
*device_path)
}
rcu_assign_pointer(device-name, name);
 
-   ret = find_next_devid(root, device-devid);
+   ret = find_next_devid(root-fs_info, device-devid);
if (ret) {
rcu_string_free(device-name);
kfree(device);
-- 
1.7.10.4

--
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] btrfs: reuse kbasename helper

2013-08-12 Thread Andy Shevchenko 
To get name of the file from a pathname let's use kbasename() helper. It allows
to simplify code a bit.

Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
 fs/btrfs/send.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index d3f3b43..4fdc99d 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -26,6 +26,7 @@
 #include linux/radix-tree.h
 #include linux/crc32c.h
 #include linux/vmalloc.h
+#include linux/string.h
 
 #include send.h
 #include backref.h
@@ -2591,20 +2592,14 @@ static int record_ref(struct list_head *head, u64 dir,
ref-dir_gen = dir_gen;
ref-full_path = path;
 
-   tmp = strrchr(ref-full_path-start, '/');
-   if (!tmp) {
-   ref-name_len = ref-full_path-end - ref-full_path-start;
-   ref-name = ref-full_path-start;
+   ref-name = kbasename(ref-full_path-start);
+   ref-name_len = ref-full_path-end - ref-name;
+   ref-dir_path = ref-full_path-start;
+   if (ref-name == ref-full_path-start)
ref-dir_path_len = 0;
-   ref-dir_path = ref-full_path-start;
-   } else {
-   tmp++;
-   ref-name_len = ref-full_path-end - tmp;
-   ref-name = tmp;
-   ref-dir_path = ref-full_path-start;
+   else
ref-dir_path_len = ref-full_path-end -
ref-full_path-start - 1 - ref-name_len;
-   }
 
list_add_tail(ref-list, head);
return 0;
-- 
1.8.4.rc1

--
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][RESEND] vfs: allow /proc/PID/maps to get device from stat

2013-08-12 Thread Christoph Hellwig 
On Thu, Aug 08, 2013 at 11:44:54AM -0400, Josef Bacik wrote:
 On Thu, Aug 08, 2013 at 06:48:05AM -0700, Christoph Hellwig wrote:
  On Thu, Aug 08, 2013 at 09:02:07AM -0400, Josef Bacik wrote:
   This won't work, try having 1 subvolumes with dirty inodes and do 
   sync then
   go skiing, you'll have time :).  Thanks,
  
  Why would the dirty inodes make any difference?  If you share the bdi
  between the subvolumes the sync workflow should be exactly the same
  still.
  
 
 If we could dis-entangle vfsmounts from sb's and have it so you could have
 multiple vfsmounts with just one sb that would solve at least the in-kernel
 confusion, but I think we still have the userspace confusion.  Thanks,

I think it would mostly solve userspace confusion, as userspace only
sees mounts and the device names.

But please fix this up properly instead of propagating the effects of
the nasty btrfs hack that should never have been merged in that form
further up the stack.

--
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: Why does btrfs benchmark so badly in this case?

2013-08-12 Thread Josef Bacik 
On Fri, Aug 09, 2013 at 11:35:33PM +0200, Kai Krakow wrote:
 Josef Bacik jba...@fusionio.com schrieb:
 
  So I guess the reason that ZFS does well with that workload is that
  ZFS is using smaller blocks, maybe just 512B ?
  
  Yeah I'm not sure what ZFS does, but if you are writing over a block and
  the size/offset isn't aligned then you'd see similar issues with ZFS since
  it would
  have to read+modify+write.  It is likely that ZFS just is using a smaller
  blocksize.
 
 From what I remember, ZFS uses dynamic block sizes. However, block size can 
 be forced and thus tuned for workloads that require it:
 
 http://www.joyent.com/blog/bruning-questions-zfs-record-size
 
 Maybe that's the reason...
 
 It would be interesting to see how the benchmarks performed with forced 
 block size.
 

When I did bs=4k in the fio job to force it to use 4k blocksizes we performed
the same as ext4 and xfs.  Thanks,

Josef
--
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] Btrfs: skip subvol entries when checking if we've created a dir already

2013-08-12 Thread Josef Bacik 
We have logic to see if we've already created a parent directory by check to see
if an inode inside of that directory has a lower inode number than the one we
are currently processing.  The logic is that if there is a lower inode number
then we would have had to made sure the directory was created at that previous
point.  The problem is if we have subvols in that directory these will always be
lower since they are set to the first free objectid.  To fix this we just skip
entries with that inode number.  Thanks,

Reported-by: Emil Karlson jekarl...@gmail.com
Signed-off-by: Josef Bacik jba...@fusionio.com
---
 fs/btrfs/send.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 0efc2e2..5c09059 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -2538,7 +2538,8 @@ static int did_create_dir(struct send_ctx *sctx, u64 dir)
di = btrfs_item_ptr(eb, slot, struct btrfs_dir_item);
btrfs_dir_item_key_to_cpu(eb, di, di_key);
 
-   if (di_key.objectid  sctx-send_progress) {
+   if (di_key.objectid != BTRFS_FIRST_FREE_OBJECTID 
+   di_key.objectid  sctx-send_progress) {
ret = 1;
goto out;
}
-- 
1.7.7.6

--
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: Possible bug in send/receive with simple reproducer

2013-08-12 Thread Josef Bacik 
On Sun, Aug 11, 2013 at 09:53:01PM +0300, Emil Karlson wrote:
 Greetings
 
 Send fails for me unexpectedly:
 
 I get:
 ERROR: rename o262-5-0 - snapshots failed. No such file or directory
 
 reproducer ( http://users.tkk.fi/~jkarlson/files/test4.txt  ):
 
 for i in 1 2; do
   mkdir /mnt/$i
   truncate -s 4G /mnt/$i.img
   mkfs.btrfs /mnt/$i.img
   mount -o loop /mnt/$i.img /mnt/$i
 done
 
 mkdir /mnt/1/testdir
 mkdir /mnt/1/testdir/1/
 mkdir /mnt/1/testdir/2/
 dd if=/dev/urandom  of=/mnt/1/testdir/aa count=16
 dd if=/dev/urandom  of=/mnt/1/testdir/bb count=16
 
 mkdir /mnt/1/snapshots
 btrfs sub snap -r /mnt/1/ /mnt/1/snapshots/backup2
 btrfs sub snap -r /mnt/1/ /mnt/1/snapshots/backup3
 btrfs send /mnt/1/snapshots/backup3/ | btrfs receive /mnt/2/
 
 umount /mnt/{1,2}; rm /mnt/{1,2}.img; rmdir /mnt/{1,2}

This was perfect, thank you for that.  I've posted a fix and I'll turn this into
an xfstest to make sure we don't ever regress.  Thanks again,

Josef
--
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: Possible bug in send/receive with simple reproducer

2013-08-12 Thread Stefan Behrens 
On Mon, 12 Aug 2013 10:59:52 -0400, Josef Bacik wrote:
 On Sun, Aug 11, 2013 at 09:53:01PM +0300, Emil Karlson wrote:
 Greetings

 Send fails for me unexpectedly:

 I get:
 ERROR: rename o262-5-0 - snapshots failed. No such file or directory

 reproducer ( http://users.tkk.fi/~jkarlson/files/test4.txt  ):

 for i in 1 2; do
   mkdir /mnt/$i
   truncate -s 4G /mnt/$i.img
   mkfs.btrfs /mnt/$i.img
   mount -o loop /mnt/$i.img /mnt/$i
 done

 mkdir /mnt/1/testdir
 mkdir /mnt/1/testdir/1/
 mkdir /mnt/1/testdir/2/
 dd if=/dev/urandom  of=/mnt/1/testdir/aa count=16
 dd if=/dev/urandom  of=/mnt/1/testdir/bb count=16

 mkdir /mnt/1/snapshots
 btrfs sub snap -r /mnt/1/ /mnt/1/snapshots/backup2
 btrfs sub snap -r /mnt/1/ /mnt/1/snapshots/backup3
 btrfs send /mnt/1/snapshots/backup3/ | btrfs receive /mnt/2/

 umount /mnt/{1,2}; rm /mnt/{1,2}.img; rmdir /mnt/{1,2}
 
 This was perfect, thank you for that.  I've posted a fix and I'll turn this 
 into
 an xfstest to make sure we don't ever regress.  Thanks again,


If you create a subvolume below /mnt/[12] and run the test there, you
have the problem reproduced again :)

for i in 1 2; do
 mkdir /mnt/$i
 truncate -s 4G /mnt/$i.img
 mkfs.btrfs /mnt/$i.img
 mount -o loop /mnt/$i.img /mnt/$i
done

btrfs subv create /mnt/1/sub
btrfs subv create /mnt/2/sub
mkdir /mnt/1/sub/testdir
mkdir /mnt/1/sub/testdir/1/
mkdir /mnt/1/sub/testdir/2/
dd if=/dev/urandom  of=/mnt/1/sub/testdir/aa count=16
dd if=/dev/urandom  of=/mnt/1/sub/testdir/bb count=16

mkdir /mnt/1/sub/snapshots
btrfs sub snap -r /mnt/1/sub/ /mnt/1/sub/snapshots/backup2
btrfs sub snap -r /mnt/1/sub/ /mnt/1/sub/snapshots/backup3
btrfs send /mnt/1/sub/snapshots/backup3/ | btrfs receive /mnt/2/sub/

umount /mnt/[12]; rm /mnt/[12].img; rmdir /mnt/[12]

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

BTRFS corruptions counter

2013-08-12 Thread Todor Ivanov 
Hi,

We decided to give BTRFS a try. We find it very flexible and generally
fast. However last week we had a problem with a Marvell controller in
AHCI and one BTRFS formatted hard drive. We isolated the problem by
relocating the disk to an Intel contoller (SATA controller: Marvell
Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 11) had a
lot of problems and I managed to overcome them by passing
libata.force=noncq for a couple of weeks, until it failed generally).
Now that the disk is on the intel contoller it works fine and data is
intact, but whenever I do mount or unmount I see:

Aug 10 18:34:47 MyServerHere kernel: btrfs: bdev /dev/sde1 errs: wr 0,
rd 0, flush 0, corrupt 166, gen 0

The problem is corrupt 166
Sofar I did:

1. btrfsck and it reported everything is OK
2. btrfs scrub start /dev/sde1 and it again reported all is OK

Am I missing something in my filesystem checks or there is another way
to zero the corrupt counter?

Regards,
Todor
--
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: BTRFS corruptions counter

2013-08-12 Thread Stefan Behrens 

On 08/12/2013 18:57, Todor Ivanov wrote:

Hi,

We decided to give BTRFS a try. We find it very flexible and generally
fast. However last week we had a problem with a Marvell controller in
AHCI and one BTRFS formatted hard drive. We isolated the problem by
relocating the disk to an Intel contoller (SATA controller: Marvell
Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 11) had a
lot of problems and I managed to overcome them by passing
libata.force=noncq for a couple of weeks, until it failed generally).
Now that the disk is on the intel contoller it works fine and data is
intact, but whenever I do mount or unmount I see:

Aug 10 18:34:47 MyServerHere kernel: btrfs: bdev /dev/sde1 errs: wr 0,
rd 0, flush 0, corrupt 166, gen 0

The problem is corrupt 166
Sofar I did:

1. btrfsck and it reported everything is OK
2. btrfs scrub start /dev/sde1 and it again reported all is OK

Am I missing something in my filesystem checks or there is another way
to zero the corrupt counter?


These counters are not reset automatically. To do this manually, run 
this command:


btrfs device stats [-z] path|device
Show current device IO stats. -z to reset stats afterwards.

If you don't have this command, you can find instructions how to compile 
updated btrgs-progs tools here:


https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories#btrfs-progs_git_repository

Additionally, read the section build dependencies which contains a 
list of packages that are required to build the tools.



--
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: Possible bug in send/receive with simple reproducer

2013-08-12 Thread Josef Bacik 
On Mon, Aug 12, 2013 at 05:16:04PM +0200, Stefan Behrens wrote:
 On Mon, 12 Aug 2013 10:59:52 -0400, Josef Bacik wrote:
  On Sun, Aug 11, 2013 at 09:53:01PM +0300, Emil Karlson wrote:
  Greetings
 
  Send fails for me unexpectedly:
 
  I get:
  ERROR: rename o262-5-0 - snapshots failed. No such file or directory
 
  reproducer ( http://users.tkk.fi/~jkarlson/files/test4.txt  ):
 
  for i in 1 2; do
mkdir /mnt/$i
truncate -s 4G /mnt/$i.img
mkfs.btrfs /mnt/$i.img
mount -o loop /mnt/$i.img /mnt/$i
  done
 
  mkdir /mnt/1/testdir
  mkdir /mnt/1/testdir/1/
  mkdir /mnt/1/testdir/2/
  dd if=/dev/urandom  of=/mnt/1/testdir/aa count=16
  dd if=/dev/urandom  of=/mnt/1/testdir/bb count=16
 
  mkdir /mnt/1/snapshots
  btrfs sub snap -r /mnt/1/ /mnt/1/snapshots/backup2
  btrfs sub snap -r /mnt/1/ /mnt/1/snapshots/backup3
  btrfs send /mnt/1/snapshots/backup3/ | btrfs receive /mnt/2/
 
  umount /mnt/{1,2}; rm /mnt/{1,2}.img; rmdir /mnt/{1,2}
  
  This was perfect, thank you for that.  I've posted a fix and I'll turn this 
  into
  an xfstest to make sure we don't ever regress.  Thanks again,
 
 
 If you create a subvolume below /mnt/[12] and run the test there, you
 have the problem reproduced again :)
 

Yeah I noticed this problem when I converted it over to an xfstest, forgot that
I'm an idiot.  Trying to figure out a less braindead way to fix this.  Thanks,

Josef
--
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] Btrfs: skip subvol entries when checking if we've created a dir already V2

2013-08-12 Thread Josef Bacik 
We have logic to see if we've already created a parent directory by check to see
if an inode inside of that directory has a lower inode number than the one we
are currently processing.  The logic is that if there is a lower inode number
then we would have had to made sure the directory was created at that previous
point.  The problem is that subvols inode numbers count from the lowest objectid
in the root tree, which may be less than our current progress.  So just skip if
our dir item key is a root item.  This fixes the original test and the xfstest
version I made that added an extra subvol create.  Thanks,

Reported-by: Emil Karlson jekarl...@gmail.com
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V1-V2: fix it properly

 fs/btrfs/send.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 0efc2e2..f8f8b1f 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -2538,7 +2538,8 @@ static int did_create_dir(struct send_ctx *sctx, u64 dir)
di = btrfs_item_ptr(eb, slot, struct btrfs_dir_item);
btrfs_dir_item_key_to_cpu(eb, di, di_key);
 
-   if (di_key.objectid  sctx-send_progress) {
+   if (di_key.type != BTRFS_ROOT_ITEM_KEY 
+   di_key.objectid  sctx-send_progress) {
ret = 1;
goto out;
}
-- 
1.7.7.6

--
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] xfstests: btrfs/002, another send regression test

2013-08-12 Thread Josef Bacik 
This is a regression test for a problem we had where we'd assume we had created
a directory if it only had subvols inside of it.  This was happening because
subvols would have lower inode numbers than our current send progress because
their inode numbers are based off of a different counter.  Thanks,

Signed-off-by: Josef Bacik jba...@fusionio.com
---
 tests/btrfs/002 |   85 +++
 tests/btrfs/002.out |2 +
 tests/btrfs/group   |1 +
 3 files changed, 88 insertions(+), 0 deletions(-)
 create mode 100755 tests/btrfs/002
 create mode 100644 tests/btrfs/002.out

diff --git a/tests/btrfs/002 b/tests/btrfs/002
new file mode 100755
index 000..d671688
--- /dev/null
+++ b/tests/btrfs/002
@@ -0,0 +1,85 @@
+#! /bin/bash
+# FS QA Test No. btrfs/002
+#
+# btrfs send ENOENT regression test, from a user report on linux-btrfs
+#
+#---
+# Copyright (c) 2013 Fusion IO.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo QA output created by $seq
+
+here=`pwd`
+tmp=/tmp/$$
+tmp_dir=send_temp_$seq
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+   $BTRFS_UTIL_PROG subvol del $TEST_DIR/$tmp_dir/send/snapshots/backup2  
/dev/null 21
+   $BTRFS_UTIL_PROG subvol del $TEST_DIR/$tmp_dir/send/snapshots/backup3  
/dev/null 21
+   $BTRFS_UTIL_PROG subvol del $TEST_DIR/$tmp_dir/send  /dev/null 21
+   rm -rf $TEST_DIR/$tmp_dir
+   rm -f $tmp.*
+}
+
+trap _cleanup ; exit \$status 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+
+_scratch_mkfs  /dev/null 21
+
+#receive needs to be able to setxattrs, including the selinux context, if we 
use
+#the normal nfs context thing it screws up our ability to set the
+#security.selinux xattrs so we need to disable this for this test
+export SELINUX_MOUNT_OPTIONS=
+
+_scratch_mount
+
+mkdir $TEST_DIR/$tmp_dir
+$BTRFS_UTIL_PROG subvol create $TEST_DIR/$tmp_dir/send \
+$seqres.full 21 || _fail failed subvol create
+work_dir=$TEST_DIR/$tmp_dir/send
+mkdir $work_dir/testdir
+mkdir $work_dir/testdir/1/
+mkdir $work_dir/testdir/2/
+dd if=/dev/urandom  of=$work_dir/testdir/aa count=16  /dev/null 21
+dd if=/dev/urandom  of=$work_dir/testdir/bb count=16  /dev/null 21
+
+mkdir $work_dir/snapshots
+$BTRFS_UTIL_PROG sub snap -r $work_dir $work_dir/snapshots/backup2 \
+$seqres.full 21 || _fail failed backup2
+$BTRFS_UTIL_PROG sub snap -r $work_dir $work_dir/snapshots/backup3 \
+$seqres.full 21 || _fail failed backup3
+$BTRFS_UTIL_PROG send $work_dir/snapshots/backup3/ -f $TEST_DIR/$tmp_dir/blah \
+$seqres.full 21 || _fail send failed
+$BTRFS_UTIL_PROG receive $SCRATCH_MNT - -f $TEST_DIR/$tmp_dir/blah \
+$seqres.full 21 || _fail receive failed
+
+echo Silence is golden
+status=0 ; exit
diff --git a/tests/btrfs/002.out b/tests/btrfs/002.out
new file mode 100644
index 000..61705c7
--- /dev/null
+++ b/tests/btrfs/002.out
@@ -0,0 +1,2 @@
+QA output created by 002
+Silence is golden
diff --git a/tests/btrfs/group b/tests/btrfs/group
index 3afa04f..0733a1d 100644
--- a/tests/btrfs/group
+++ b/tests/btrfs/group
@@ -4,6 +4,7 @@
 # - comment line before each group is new description
 #
 001 auto quick
+002 auto quick
 254 auto quick
 264 auto
 265 auto
-- 
1.7.7.6

--
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] xfstests: btrfs/002, another send regression test

2013-08-12 Thread Eric Sandeen 
On 8/12/13 2:13 PM, Josef Bacik wrote:
 This is a regression test for a problem we had where we'd assume we had 
 created
 a directory if it only had subvols inside of it.  This was happening because
 subvols would have lower inode numbers than our current send progress because
 their inode numbers are based off of a different counter.  Thanks,

The problem itself isn't totally clear to me, but the test itself looks
fine.  ;)

 Signed-off-by: Josef Bacik jba...@fusionio.com

Reviewed-by: Eric Sandeen sand...@redhat.com

 ---
  tests/btrfs/002 |   85 
 +++
  tests/btrfs/002.out |2 +
  tests/btrfs/group   |1 +
  3 files changed, 88 insertions(+), 0 deletions(-)
  create mode 100755 tests/btrfs/002
  create mode 100644 tests/btrfs/002.out
 
 diff --git a/tests/btrfs/002 b/tests/btrfs/002
 new file mode 100755
 index 000..d671688
 --- /dev/null
 +++ b/tests/btrfs/002
 @@ -0,0 +1,85 @@
 +#! /bin/bash
 +# FS QA Test No. btrfs/002
 +#
 +# btrfs send ENOENT regression test, from a user report on linux-btrfs
 +#
 +#---
 +# Copyright (c) 2013 Fusion IO.  All Rights Reserved.
 +#
 +# This program is free software; you can redistribute it and/or
 +# modify it under the terms of the GNU General Public License as
 +# published by the Free Software Foundation.
 +#
 +# This program is distributed in the hope that it would be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with this program; if not, write the Free Software Foundation,
 +# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 +#
 +#---
 +#
 +
 +seq=`basename $0`
 +seqres=$RESULT_DIR/$seq
 +echo QA output created by $seq
 +
 +here=`pwd`
 +tmp=/tmp/$$
 +tmp_dir=send_temp_$seq
 +
 +status=1 # failure is the default!
 +
 +_cleanup()
 +{
 + $BTRFS_UTIL_PROG subvol del $TEST_DIR/$tmp_dir/send/snapshots/backup2  
 /dev/null 21
 + $BTRFS_UTIL_PROG subvol del $TEST_DIR/$tmp_dir/send/snapshots/backup3  
 /dev/null 21
 + $BTRFS_UTIL_PROG subvol del $TEST_DIR/$tmp_dir/send  /dev/null 21
 + rm -rf $TEST_DIR/$tmp_dir
 + rm -f $tmp.*
 +}
 +
 +trap _cleanup ; exit \$status 0 1 2 3 15
 +
 +# get standard environment, filters and checks
 +. ./common/rc
 +. ./common/filter
 +
 +# real QA test starts here
 +_supported_fs btrfs
 +_supported_os Linux
 +_require_scratch
 +
 +_scratch_mkfs  /dev/null 21
 +
 +#receive needs to be able to setxattrs, including the selinux context, if we 
 use
 +#the normal nfs context thing it screws up our ability to set the
 +#security.selinux xattrs so we need to disable this for this test
 +export SELINUX_MOUNT_OPTIONS=
 +
 +_scratch_mount
 +
 +mkdir $TEST_DIR/$tmp_dir
 +$BTRFS_UTIL_PROG subvol create $TEST_DIR/$tmp_dir/send \
 +  $seqres.full 21 || _fail failed subvol create
 +work_dir=$TEST_DIR/$tmp_dir/send
 +mkdir $work_dir/testdir
 +mkdir $work_dir/testdir/1/
 +mkdir $work_dir/testdir/2/
 +dd if=/dev/urandom  of=$work_dir/testdir/aa count=16  /dev/null 21
 +dd if=/dev/urandom  of=$work_dir/testdir/bb count=16  /dev/null 21
 +
 +mkdir $work_dir/snapshots
 +$BTRFS_UTIL_PROG sub snap -r $work_dir $work_dir/snapshots/backup2 \
 +  $seqres.full 21 || _fail failed backup2
 +$BTRFS_UTIL_PROG sub snap -r $work_dir $work_dir/snapshots/backup3 \
 +  $seqres.full 21 || _fail failed backup3
 +$BTRFS_UTIL_PROG send $work_dir/snapshots/backup3/ -f 
 $TEST_DIR/$tmp_dir/blah \
 +  $seqres.full 21 || _fail send failed
 +$BTRFS_UTIL_PROG receive $SCRATCH_MNT - -f $TEST_DIR/$tmp_dir/blah \
 +  $seqres.full 21 || _fail receive failed
 +
 +echo Silence is golden
 +status=0 ; exit
 diff --git a/tests/btrfs/002.out b/tests/btrfs/002.out
 new file mode 100644
 index 000..61705c7
 --- /dev/null
 +++ b/tests/btrfs/002.out
 @@ -0,0 +1,2 @@
 +QA output created by 002
 +Silence is golden
 diff --git a/tests/btrfs/group b/tests/btrfs/group
 index 3afa04f..0733a1d 100644
 --- a/tests/btrfs/group
 +++ b/tests/btrfs/group
 @@ -4,6 +4,7 @@
  # - comment line before each group is new description
  #
  001 auto quick
 +002 auto quick
  254 auto quick
  264 auto
  265 auto
 

--
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] Btrfs: don't allow a subvol to be deleted if it is the default subovl

2013-08-12 Thread Josef Bacik 
Eric pointed out that btrfs will happily allow you to delete the default subvol.
This is a problem obviously since the next time you go to mount the file system
it will freak out because it can't find the root.  Fix this by adding a check to
see if our default subvol points to the subvol we are trying to delete, and if
it does not allowing it to happen.  Thanks,

Signed-off-by: Josef Bacik jba...@fusionio.com
---
 fs/btrfs/ioctl.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 2312c0f..107c5f4 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1726,13 +1726,28 @@ out:
 static noinline int may_destroy_subvol(struct btrfs_root *root)
 {
struct btrfs_path *path;
+   struct btrfs_dir_item *di;
struct btrfs_key key;
+   u64 dir_id;
int ret;
 
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
 
+   /* Make sure this root isn't set as the default subvol */
+   dir_id = btrfs_super_root_dir(root-fs_info-super_copy);
+   di = btrfs_lookup_dir_item(NULL, root-fs_info-tree_root, path,
+  dir_id, default, 7, 0);
+   if (di  !IS_ERR(di)) {
+   btrfs_dir_item_key_to_cpu(path-nodes[0], di, key);
+   if (key.objectid == root-root_key.objectid) {
+   ret = -ENOTEMPTY;
+   goto out;
+   }
+   btrfs_release_path(path);
+   }
+
key.objectid = root-root_key.objectid;
key.type = BTRFS_ROOT_REF_KEY;
key.offset = (u64)-1;
-- 
1.7.7.6

--
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] xfstests: btrfs/003: regression test for subvol delete

2013-08-12 Thread Josef Bacik 
We were allowing users to delete their default subvolume, which is problematic.
This test is a regression test to make sure we don't let that happen in the
future.  Thanks,

Signed-off-by: Josef Bacik jba...@fusionio.com
---
 tests/btrfs/003 |   64 +++
 tests/btrfs/003.out |2 +
 tests/btrfs/group   |1 +
 3 files changed, 67 insertions(+), 0 deletions(-)
 create mode 100755 tests/btrfs/003
 create mode 100644 tests/btrfs/003.out

diff --git a/tests/btrfs/003 b/tests/btrfs/003
new file mode 100755
index 000..775322a
--- /dev/null
+++ b/tests/btrfs/003
@@ -0,0 +1,64 @@
+#! /bin/bash
+# FS QA Test No. btrfs/003
+#
+# Regression test to make sure we can't delete the default subvol
+#
+#---
+# Copyright (c) 2013 Fusion IO.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo QA output created by $seq
+
+here=`pwd`
+tmp=/tmp/$$
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+   rm -f $tmp.*
+}
+
+trap _cleanup ; exit \$status 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+
+_scratch_mkfs  /dev/null 21
+_scratch_mount
+
+# This will be set to subvolid 256.  If this ever changes in the future for
+# whatever reason we'll have to pull the subvolid out of the subvol list 
command
+# but since it's a newly mkfs'ed fs we should be fine with this.
+$BTRFS_UTIL_PROG sub create $SCRATCH_MNT/newvol  $seqres.full 21 \
+   || _fail couldnt create subvol
+$BTRFS_UTIL_PROG sub set-default 256 $SCRATCH_MNT  $seqres.full 21 \
+   || _fail couldn't set default
+$BTRFS_UTIL_PROG sub delete $SCRATCH_MNT/newvol  $seqres.full 21
+[ $? -eq 0 ]  _fail delete succeeded, should have failed
+
+echo Silence is golden
+status=0 ; exit
diff --git a/tests/btrfs/003.out b/tests/btrfs/003.out
new file mode 100644
index 000..6895fc8
--- /dev/null
+++ b/tests/btrfs/003.out
@@ -0,0 +1,2 @@
+QA output created by 003
+Silence is golden
diff --git a/tests/btrfs/group b/tests/btrfs/group
index 0733a1d..44b2f8e 100644
--- a/tests/btrfs/group
+++ b/tests/btrfs/group
@@ -5,6 +5,7 @@
 #
 001 auto quick
 002 auto quick
+003 auto quick
 254 auto quick
 264 auto
 265 auto
-- 
1.7.7.6

--
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] Btrfs: fix race conditions in BTRFS_IOC_FS_INFO ioctl

2013-08-12 Thread Filipe David Borba Manana 
The handler for the ioctl BTRFS_IOC_FS_INFO was reading the
number of devices before acquiring the device list mutex.

This could lead to inconsistent results because the update of
the device list and the number of devices counter (amongst other
counters related to the device list) are updated in volumes.c
while holding the device list mutex - except for 2 places, one
was volumes.c:btrfs_prepare_sprout() and the other was
volumes.c:device_list_add().

For example, if we have 2 devices, with IDs 1 and 2 and then add
a new device, with ID 3, and while adding the device is in progress
an BTRFS_IOC_FS_INFO ioctl arrives, it could return a number of
devices of 2 and a max dev id of 3. This would be incorrect.

Also, this ioctl handler was reading the fsid while it can be
updated concurrently. This can happen when while a new device is
being added and the current filesystem is in seeding mode.
Example:

$ mkfs.btrfs -f /dev/sdb1
$ mkfs.btrfs -f /dev/sdb2
$ btrfstune -S 1 /dev/sdb1
$ mount /dev/sdb1 /mnt/test
$ btrfs device add /dev/sdb2 /mnt/test

If during the last step a BTRFS_IOC_FS_INFO ioctl was requested, it
could read an fsid that was never valid (some bits part of the old
fsid and others part of the new fsid). Also, it could read a number
of devices that doesn't match the number of devices in the list and
the max device id, as explained before.

Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
 fs/btrfs/ioctl.c   |2 +-
 fs/btrfs/volumes.c |5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 2312c0f..8484de3 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2405,10 +2405,10 @@ static long btrfs_ioctl_fs_info(struct btrfs_root 
*root, void __user *arg)
if (!fi_args)
return -ENOMEM;
 
+   mutex_lock(fs_devices-device_list_mutex);
fi_args-num_devices = fs_devices-num_devices;
memcpy(fi_args-fsid, root-fs_info-fsid, sizeof(fi_args-fsid));
 
-   mutex_lock(fs_devices-device_list_mutex);
list_for_each_entry_safe(device, next, fs_devices-devices, dev_list) {
if (device-devid  fi_args-max_id)
fi_args-max_id = device-devid;
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 44abd15..4f465fc 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -444,10 +444,10 @@ static noinline int device_list_add(const char *path,
 
mutex_lock(fs_devices-device_list_mutex);
list_add_rcu(device-dev_list, fs_devices-devices);
+   fs_devices-num_devices++;
mutex_unlock(fs_devices-device_list_mutex);
 
device-fs_devices = fs_devices;
-   fs_devices-num_devices++;
} else if (!device-name || strcmp(device-name-str, path)) {
name = rcu_string_strdup(path, GFP_NOFS);
if (!name)
@@ -1816,7 +1816,6 @@ static int btrfs_prepare_sprout(struct btrfs_root *root)
mutex_lock(root-fs_info-fs_devices-device_list_mutex);
list_splice_init_rcu(fs_devices-devices, seed_devices-devices,
  synchronize_rcu);
-   mutex_unlock(root-fs_info-fs_devices-device_list_mutex);
 
list_splice_init(fs_devices-alloc_list, seed_devices-alloc_list);
list_for_each_entry(device, seed_devices-devices, dev_list) {
@@ -1832,6 +1831,8 @@ static int btrfs_prepare_sprout(struct btrfs_root *root)
generate_random_uuid(fs_devices-fsid);
memcpy(root-fs_info-fsid, fs_devices-fsid, BTRFS_FSID_SIZE);
memcpy(disk_super-fsid, fs_devices-fsid, BTRFS_FSID_SIZE);
+   mutex_unlock(root-fs_info-fs_devices-device_list_mutex);
+
super_flags = btrfs_super_flags(disk_super) 
  ~BTRFS_SUPER_FLAG_SEEDING;
btrfs_set_super_flags(disk_super, super_flags);
-- 
1.7.9.5

--
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] xfstests: btrfs/003: regression test for subvol delete

2013-08-12 Thread Eric Sandeen 
On 8/12/13 2:40 PM, Josef Bacik wrote:
 We were allowing users to delete their default subvolume, which is 
 problematic.
 This test is a regression test to make sure we don't let that happen in the
 future.  Thanks,
 
 Signed-off-by: Josef Bacik jba...@fusionio.com
 ---
  tests/btrfs/003 |   64 
 +++
  tests/btrfs/003.out |2 +
  tests/btrfs/group   |1 +
  3 files changed, 67 insertions(+), 0 deletions(-)
  create mode 100755 tests/btrfs/003
  create mode 100644 tests/btrfs/003.out
 
 diff --git a/tests/btrfs/003 b/tests/btrfs/003
 new file mode 100755
 index 000..775322a
 --- /dev/null
 +++ b/tests/btrfs/003
 @@ -0,0 +1,64 @@
 +#! /bin/bash
 +# FS QA Test No. btrfs/003
 +#
 +# Regression test to make sure we can't delete the default subvol
 +#
 +#---
 +# Copyright (c) 2013 Fusion IO.  All Rights Reserved.
 +#
 +# This program is free software; you can redistribute it and/or
 +# modify it under the terms of the GNU General Public License as
 +# published by the Free Software Foundation.
 +#
 +# This program is distributed in the hope that it would be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with this program; if not, write the Free Software Foundation,
 +# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 +#
 +#---
 +#
 +
 +seq=`basename $0`
 +seqres=$RESULT_DIR/$seq
 +echo QA output created by $seq
 +
 +here=`pwd`
 +tmp=/tmp/$$
 +
 +status=1 # failure is the default!
 +
 +_cleanup()
 +{
 + rm -f $tmp.*
 +}
 +
 +trap _cleanup ; exit \$status 0 1 2 3 15
 +
 +# get standard environment, filters and checks
 +. ./common/rc
 +. ./common/filter
 +
 +# real QA test starts here
 +_supported_fs btrfs
 +_supported_os Linux
 +_require_scratch
 +
 +_scratch_mkfs  /dev/null 21
 +_scratch_mount
 +
 +# This will be set to subvolid 256.  If this ever changes in the future for
 +# whatever reason we'll have to pull the subvolid out of the subvol list 
 command
 +# but since it's a newly mkfs'ed fs we should be fine with this.

Is it that hard to just do it right the first time?  I'd rather see
it extracted properly... (perhaps with a helper?)

 +$BTRFS_UTIL_PROG sub create $SCRATCH_MNT/newvol  $seqres.full 21 \
 + || _fail couldnt create subvol
 +$BTRFS_UTIL_PROG sub set-default 256 $SCRATCH_MNT  $seqres.full 21 \
 + || _fail couldn't set default

you spelled couldn't with and without a ' - while you're at it.  ;)

 +$BTRFS_UTIL_PROG sub delete $SCRATCH_MNT/newvol  $seqres.full 21
 +[ $? -eq 0 ]  _fail delete succeeded, should have failed

Maybe umount  mount since that was the originally detected failure
(rather than simply relying on the exit status?)

-Eric

 +echo Silence is golden
 +status=0 ; exit
 diff --git a/tests/btrfs/003.out b/tests/btrfs/003.out
 new file mode 100644
 index 000..6895fc8
 --- /dev/null
 +++ b/tests/btrfs/003.out
 @@ -0,0 +1,2 @@
 +QA output created by 003
 +Silence is golden
 diff --git a/tests/btrfs/group b/tests/btrfs/group
 index 0733a1d..44b2f8e 100644
 --- a/tests/btrfs/group
 +++ b/tests/btrfs/group
 @@ -5,6 +5,7 @@
  #
  001 auto quick
  002 auto quick
 +003 auto quick
  254 auto quick
  264 auto
  265 auto
 

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

btrfs-ino-cache is running on each reboot

2013-08-12 Thread dima 

Hello all,

About a week or so ago I noticed that [btrfs-ino-cache] process was 
appearing in the 'top' on each reboot and disk is spinning like crazy 
for about five minutes or so. Quite so often this caused X failing to 
start because all I/O was busy with caching.
Even after letting it to calm down and seeing [btrfs-ino-cache] 
disappearing from the process list, on next reboot it starts all over again.


Here is the fstab entry that I have

UUID=430dca92-9541-4201-0f62-373e30beadac / btrfs 
subvol=root_subvolume,defaults,noatime,noacl,compress=lzo,inode_cache,space_cache,autodefrag 
0 0


inode_cache was always enabled since the FS was created about a year or 
so ago, and actually I have never had any problems with it up until 
recently.


Removing inode_cache option from fstab solves the problem, but I am not 
sure if it is the right choice.
I can observe the problem at least in the vanilla kernel 3.10.4 ~ 6 (did 
not try older versions)


What could be the reason for such behavior and how to avoid it?

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

Kernel BUG on Snapshot Deletion (3.11.0-rc5)

2013-08-12 Thread Mitch Harder 
I'm hitting a btrfs Kernel BUG running a snapshot stress script with
linux-3.11.0-rc5.

I'm running with lzo compression, autodefrag, and the partition is
formated with 16k leafsize/inodesize.

[   72.170431] device fsid 8a6be667-d041-4367-80f7-e4cb42356e85 devid
1 transid 4 /dev/sda7
[   72.297512] device fsid 8a6be667-d041-4367-80f7-e4cb42356e85 devid
1 transid 4 /dev/sda7
[   72.298928] device fsid 8a6be667-d041-4367-80f7-e4cb42356e85 devid
1 transid 4 /dev/sda7
[   72.299390] btrfs: setting 8 feature flag
[   72.299395] btrfs: force lzo compression
[   72.299401] btrfs: enabling auto defrag
[   72.299404] btrfs: disk space caching is enabled
[   72.299407] btrfs flagging fs with big metadata feature
[ 2234.790218] [ cut here ]
[ 2234.790257] WARNING: CPU: 0 PID: 4246 at fs/btrfs/extent-tree.c:840
btrfs_lookup_extent_info+0x328/0x36e [btrfs]()
[ 2234.790262] Modules linked in: ipv6 tg3 serio_raw ppdev
snd_hda_codec_analog iTCO_wdt iTCO_vendor_support snd_hda_intel floppy
snd_hda_codec sr_mod snd_hwdep pcspkr snd_pcm lpc_ich i2c_i801
parport_pc parport ptp snd_page_alloc pps_core snd_timer snd xts
ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 sha256_generic
fuse xfs nfs lockd sunrpc reiserfs btrfs zlib_deflate ext4 jbd2 ext3
jbd ext2 mbcache sl811_hcd hid_generic xhci_hcd ohci_hcd uhci_hcd
ehci_pci ehci_hcd
[ 2234.790333] CPU: 0 PID: 4246 Comm: btrfs-cleaner Not tainted 3.11.0-rc5 #1
[ 2234.790337] Hardware name: Dell Inc. OptiPlex 745
  /0WF810, BIOS 2.6.4  03/01/2010
[ 2234.790341]  0348 880077739b68 81625def
0006
[ 2234.790349]   880077739ba8 810374f0
88000556e800
[ 2234.790356]  a0185d5c 88007721de10 88000556e800

[ 2234.790363] Call Trace:
[ 2234.790375]  [81625def] dump_stack+0x46/0x58
[ 2234.790384]  [810374f0] warn_slowpath_common+0x81/0x9b
[ 2234.790403]  [a0185d5c] ?
btrfs_lookup_extent_info+0x328/0x36e [btrfs]
[ 2234.790411]  [81037524] warn_slowpath_null+0x1a/0x1c
[ 2234.790429]  [a0185d5c]
btrfs_lookup_extent_info+0x328/0x36e [btrfs]
[ 2234.790449]  [a018837e] do_walk_down+0x142/0x438 [btrfs]
[ 2234.790467]  [a01860d4] ?
btrfs_delayed_refs_qgroup_accounting+0xbd/0xcc [btrfs]
[ 2234.790487]  [a018871a] walk_down_tree+0xa6/0xd4 [btrfs]
[ 2234.790507]  [a018aec3] btrfs_drop_snapshot+0x32d/0x65d [btrfs]
[ 2234.790531]  [a019b1df]
btrfs_clean_one_deleted_snapshot+0xda/0x103 [btrfs]
[ 2234.790552]  [a0193c0c] cleaner_kthread+0x130/0x157 [btrfs]
[ 2234.790573]  [a0193adc] ? transaction_kthread+0x1a0/0x1a0 [btrfs]
[ 2234.790580]  [810522bc] kthread+0xba/0xc2
[ 2234.790586]  [81052202] ? kthread_freezable_should_stop+0x52/0x52
[ 2234.790593]  [8162d89c] ret_from_fork+0x7c/0xb0
[ 2234.790599]  [81052202] ? kthread_freezable_should_stop+0x52/0x52
[ 2234.790604] ---[ end trace 21a428587abe0e9d ]---
[ 2234.790610] BTRFS error (device sda7): Missing references.
[ 2234.790637] [ cut here ]
[ 2234.790688] kernel BUG at fs/btrfs/extent-tree.c:7191!
[ 2234.790736] invalid opcode:  [#1] SMP
[ 2234.790779] Modules linked in: ipv6 tg3 serio_raw ppdev
snd_hda_codec_analog iTCO_wdt iTCO_vendor_support snd_hda_intel floppy
snd_hda_codec sr_mod snd_hwdep pcspkr snd_pcm lpc_ich i2c_i801
parport_pc parport ptp snd_page_alloc pps_core snd_timer snd xts
ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 sha256_generic
fuse xfs nfs lockd sunrpc reiserfs btrfs zlib_deflate ext4 jbd2 ext3
jbd ext2 mbcache sl811_hcd hid_generic xhci_hcd ohci_hcd uhci_hcd
ehci_pci ehci_hcd
[ 2234.791005] CPU: 0 PID: 4246 Comm: btrfs-cleaner Tainted: G
W3.11.0-rc5 #1
[ 2234.791005] Hardware name: Dell Inc. OptiPlex 745
  /0WF810, BIOS 2.6.4  03/01/2010
[ 2234.791005] task: 88007c97c380 ti: 880077738000 task.ti:
880077738000
[ 2234.791005] RIP: 0010:[a01883be]  [a01883be]
do_walk_down+0x182/0x438 [btrfs]
[ 2234.791005] RSP: :880077739c58  EFLAGS: 00010296
[ 2234.791005] RAX: 002e RBX: 88000c6706c0 RCX: 0046
[ 2234.791005] RDX: 0006 RSI: 0046 RDI: 88007f20d210
[ 2234.791005] RBP: 880077739d18 R08: 0002 R09: fffe
[ 2234.791005] R10: 0001 R11: 81e2ee38 R12: 88002a930500
[ 2234.791005] R13: 88007721 R14: 88000556e800 R15: 0002
[ 2234.791005] FS:  () GS:88007f20()
knlGS:
[ 2234.791005] CS:  0010 DS:  ES:  CR0: 8005003b
[ 2234.791005] CR2: 7f312ced67bd CR3: 255e CR4: 07f0
[ 2234.791005] Stack:
[ 2234.791005]  88000c670708 a01860d4 
8800771df3c0
[ 2234.791005]  880077739c98 0001 0001

Re: [PATCH 06/11] btrfs-progs: scan /dev/mapper in filesystem show and device scan

2013-08-12 Thread anand jain 



On 06/08/2013 01:04, David Sterba wrote:

On Mon, Jul 15, 2013 at 01:30:52PM +0800, Anand Jain wrote:

This patch adds --mapper option to btrfs device scan and
btrfs filesystem show cli, when used will look for btrfs
devs under /dev/mapper and will use the links provided
under the /dev/mapper.



In the long run I want the usage of /dev/mapper path
(along with /proc/partitions) be the default option to
scan for the btrfs devs. (/proc/partitions must be scanned
as well because to include the mapper blacklisted devs.)


Well, we want to avoid using own scanning and always consult the blkid
cache, so I'd rather stop adding user-visible changes to this command.





 here is a test prog t (attached inline below) using blkid.
 t picks up both non multipath path and mapper path as below.

# ./t
Device: /dev/sdbb03095dc-8eb5-40c9-8790-da6977110799
Device: /dev/sdcabc347f2-dfcc-46bf-a4ac-e21fba7ff1a3
Device: /dev/mapper/mpatha  b03095dc-8eb5-40c9-8790-da6977110799
Device: /dev/mapper/mpathb  abc347f2-dfcc-46bf-a4ac-e21fba7ff1a3
Found 4
--

 However when

 /etc/multipath.conf
 defaults {
user_friendly_names no
 }

 then the mapper paths are not friendly enough to use
---
# ./t
Device: /dev/sdbb03095dc-8eb5-40c9-8790-da6977110799
Device: /dev/sdcabc347f2-dfcc-46bf-a4ac-e21fba7ff1a3
Device: /dev/mapper/1ATA VBOX HARDDISK VB96b6139c-83f38bf1 
b03095dc-8eb5-40c9-8790-da6977110799
Device: /dev/mapper/1ATA VBOX HARDDISK VBc6ab3781-f63da170 
abc347f2-dfcc-46bf-a4ac-e21fba7ff1a3

Found 4
--

 in this case the /dev/dm-n would have been better to use.
 and our own scan does the better job here.. as it
 reads /proc/partition and gives priority to dm-n paths
--
btrfs fi show
Label: none  uuid: abc347f2-dfcc-46bf-a4ac-e21fba7ff1a3
Total devices 1 FS bytes used 28.00KiB
devid1 size 2.00GiB used 240.75MiB path /dev/dm-1

Label: none  uuid: b03095dc-8eb5-40c9-8790-da6977110799
Total devices 1 FS bytes used 28.00KiB
devid1 size 1.98GiB used 238.25MiB path /dev/dm-0
---

 so as of now having our scan is better than blkid.

 Now for the users who want to use the user friendly name
 provided by mapper. the newly introduced option --mapper
 which just looks under /dev/mapper will help.

Thanks, Anand


t.c--
#include stdio.h
#include blkid/blkid.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include string.h

main()
{
char *type;
char str[100];
int total = 0;
blkid_dev_iterate iter = NULL;
blkid_dev dev = NULL;
blkid_cache cache = NULL;

memset(str, '0', 100);
if (blkid_get_cache(cache, 0)  0)
return -1;

blkid_probe_all(cache);
iter = blkid_dev_iterate_begin(cache);
//blkid_dev_set_search(iter, NULL, NULL);
blkid_dev_set_search(iter, TYPE, btrfs);

while (blkid_dev_next(iter, dev) == 0) {
dev = blkid_verify(cache, dev);
if (!dev)
continue;
else {
total++;
printf(Device: %s\t%s\n,
blkid_dev_devname(dev),
blkid_get_tag_value(cache,UUID,
blkid_dev_devname(dev)));
}
}
blkid_dev_iterate_end(iter);
printf(Found %d\n, total);
return total;
}

--
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: btrfs-ino-cache is running on each reboot

2013-08-12 Thread Duncan 
dima posted on Tue, 13 Aug 2013 10:28:59 +0900 as excerpted:

 About a week or so ago I noticed that [btrfs-ino-cache] process was
 appearing in the 'top' on each reboot and disk is spinning like crazy
 for about five minutes or so. Quite so often this caused X failing to
 start because all I/O was busy with caching.
 Even after letting it to calm down and seeing [btrfs-ino-cache]
 disappearing from the process list, on next reboot it starts all over
 again.

 inode_cache was always enabled since the FS was created about a year or
 so ago, and actually I have never had any problems with it up until
 recently.
 
 Removing inode_cache option from fstab solves the problem, but I am not
 sure if it is the right choice.

A number of people have reported problems with inode_cache enabled, and 
the recommendation has always been to turn it off unless you need it.  
Easy enough problem to fix, I guess. =:^)

Of course that immediately invites the question of why have the option at 
all if all it does is cause trouble, and (as a user not a dev) I don't 
have the answer to that.  I don't know the use case when unless you need 
it would actually apply, but apparently, it does in some cases.

I guess the wiki[1] should really have a warning on that option, but 
without a more solid reason than just don't turn it on, causes more 
trouble than it's worth, I'd feel kind of goofy adding it.

Anyway, yes, the general recommendation on the list at this point seems 
to be to simply leave inode_cache off and not worry about it.

---
[1] https://btrfs.wiki.kernel.org/

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

--
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] Btrfs: don't allow a subvol to be deleted if it is the default subovl

2013-08-12 Thread Duncan 
Josef Bacik posted on Mon, 12 Aug 2013 15:39:35 -0400 as excerpted:

 Fix this by adding a check to see if our default subvol points to the
 subvol we are trying to delete, and if it does not allowing it to
 happen.

Umm... not to be a grammar policeman, but...

That last sub-sentence REALLY (!!) needs another comma:

... and if it does, not allowing it to happen.

or

... and if it does not, allowing it to happen.

The way it is now ends up triggering for the reader a serious logical 
train wreck, as does not and not allowing both want to be parsed 
together, but does not allowing derails the whole thing and the reader 
must start over, taking it more slowly this time, trying to figure out 
where the parsing derailed the first time through and what was actually 
intended!

(FWIW, being a languagelog.net feed subscriber and regular reader, I see 
instances of this sort of logical train wreck, as it's frequently 
analogized, feature there regularly.  Linguists know it as an interesting 
quirk of the English language both created and spotted regularly by 
experts and novices alike, sometimes with rather amusing consequences!)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

--
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: btrfs-ino-cache is running on each reboot

2013-08-12 Thread dima 

On 08/13/2013 01:09 PM, Duncan wrote:

dima posted on Tue, 13 Aug 2013 10:28:59 +0900 as excerpted:


About a week or so ago I noticed that [btrfs-ino-cache] process was
appearing in the 'top' on each reboot and disk is spinning like crazy
for about five minutes or so. Quite so often this caused X failing to
start because all I/O was busy with caching.
Even after letting it to calm down and seeing [btrfs-ino-cache]
disappearing from the process list, on next reboot it starts all over
again.



inode_cache was always enabled since the FS was created about a year or
so ago, and actually I have never had any problems with it up until
recently.

Removing inode_cache option from fstab solves the problem, but I am not
sure if it is the right choice.


A number of people have reported problems with inode_cache enabled, and
the recommendation has always been to turn it off unless you need it.
Easy enough problem to fix, I guess. =:^)

Of course that immediately invites the question of why have the option at
all if all it does is cause trouble, and (as a user not a dev) I don't
have the answer to that.  I don't know the use case when unless you need
it would actually apply, but apparently, it does in some cases.

I guess the wiki[1] should really have a warning on that option, but
without a more solid reason than just don't turn it on, causes more
trouble than it's worth, I'd feel kind of goofy adding it.

Anyway, yes, the general recommendation on the list at this point seems
to be to simply leave inode_cache off and not worry about it.



Thanks Duncan. So I did.
I was just wondering why it stopped behaving all of a sudden.




---
[1] https://btrfs.wiki.kernel.org/


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