[PATCH] btrfs: use list_for_each_entry_safe() when delete items

2013-07-27 Thread Azat Khuzhin
Replace list_for_each_entry() by list_for_each_entry_safe() in
__btrfs_close_devices()

There is another place that delete items lock_stripe_add(), but there we
don't need safe version, because after deleting we exit from loop.

Signed-off-by: Azat Khuzhin a3at.m...@gmail.com
---
 fs/btrfs/volumes.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 78b8717..1d1b595 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -616,13 +616,13 @@ static void free_device(struct rcu_head *head)
 
 static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
 {
-   struct btrfs_device *device;
+   struct btrfs_device *device, *next;
 
if (--fs_devices-opened  0)
return 0;
 
mutex_lock(fs_devices-device_list_mutex);
-   list_for_each_entry(device, fs_devices-devices, dev_list) {
+   list_for_each_entry_safe(device, next, fs_devices-devices, dev_list) {
struct btrfs_device *new_device;
struct rcu_string *name;
 
-- 
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


Mount multiple-device-filesystem by UUID

2013-07-27 Thread Hendrik Friedel

Hello,

As stated in the
--
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


Mount multiple-device-filesystem by UUID

2013-07-27 Thread Hendrik Friedel

Hello,

As stated in the wiki, multiple-device filesystems (e.g. raid 1) will 
only mount after a btfs device scan, or if all devices are passed with 
the mount options.


I remember, that for Ubuntu 12.04 I changed the initrd. But after a 
re-install, I have to do this again, and I don't remember how I did it.


So, the other option would be passing the devices in the fstab. But 
here, I'd prefer UUIDs rather than device names, as they can change.


Is this possible? What is the syntax?

Regards,
Hendrik


--
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: Mount multiple-device-filesystem by UUID

2013-07-27 Thread Hugo Mills
On Sat, Jul 27, 2013 at 08:52:50PM +0200, Hendrik Friedel wrote:
 As stated in the wiki, multiple-device filesystems (e.g. raid 1)
 will only mount after a btfs device scan, or if all devices are
 passed with the mount options.
 
 I remember, that for Ubuntu 12.04 I changed the initrd. But after a
 re-install, I have to do this again, and I don't remember how I did
 it.

   With Ubuntu, just install the btrfs-tools package. It should modify
the initrd correctly.

 So, the other option would be passing the devices in the fstab. But
 here, I'd prefer UUIDs rather than device names, as they can change.

   This is why we don't recommend using device= mount flags.

 Is this possible? What is the syntax?

   I don't believe it is possible. Finding filesystems by UUID is (I
think) a userspace-based thing, so you'd have to have an initrd
anyway.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- No!  My collection of rare, incurable diseases! Violated! ---   


signature.asc
Description: Digital signature


Recovering from btrfs error Couldn't read chunk root.

2013-07-27 Thread Kyriakos
I accidentally dd'ed the wrong disc /dev/sdb when it should be
/dev/sdc but i stopped in something like 2 sec. and a small part of my
2tb disc was overwritten with openSUSE  milestone 3 the ruby baked
yast flavor :).

I was able to see, access and use my data in the /dev/sdb disc, but
not after the reboot, so at the moment unsuccessfully am trying to
mount with different options like:

mount -t btrfs -o compress=lzo /dev/sdb /mnt/Kyrios
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail or so

Or
mount /dev/sdb /mnt/Kyrios
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail or so
Or
mount -t /dev/sdb /mnt/Kyrios
mount: can't find /mnt/Kyrios in /etc/fstab

Or
mount -t btrfs -o compress=lzo /dev/sdb /mnt/Kyrios
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail or so

LABEL=btrfs /mnt/Kyrios btrfs noatime, compress=lzo 0 0
bash: /mnt/Kyrios: Is a directory

btrfs subvolume list /mnt/Kyrios/Media
ERROR: error accessing '/mnt/Kyrios/Media'

My btrfs fi show output:
failed to read /dev/sr0
Label: 'Kyrios'  uuid: b5d84724-f93a-4478-a3eb-3c45c7e5ac72
Total devices 1 FS bytes used 1.57TB
devid1 size 1.82TB used 1.58TB path /dev/sdb

My btrfs fi df output:
btrfs fi df /dev/sdb
ERROR: couldn't get space info on '/dev/sdb' - Inappropriate ioctl for device

My btrfsck output:
btrfsck /dev/sdb
Check tree block failed, want=20971520, have=14982790533290893935
Check tree block failed, want=20971520, have=14982790533290893935
Check tree block failed, want=20971520, have=15644090216945910062
Check tree block failed, want=20971520, have=14982790533290893935
Check tree block failed, want=20971520, have=14982790533290893935
read block failed check_tree_block
Couldn't read chunk root
Segmentation fault (core dumped)

My blkid output:
/dev/sdb: LABEL=Kyrios UUID=b5d84724-f93a-4478-a3eb-3c45c7e5ac72
UUID_SUB=22a11e2f-7347-4aee-b490-9d9a8f3b9425 TYPE=btrfs
/dev/sda1: UUID=A270FB3270FB0C33 TYPE=ntfs
/dev/sda2: LABEL=Swap UUID=517fc7b8-3b92-4f21-8761-4ffb8af74e0d TYPE=swap
/dev/sda3: UUID=e3be6b5b-0d8c-4731-bfe1-10510fd50b79 TYPE=ext4

dmesg output:
btrfs loaded
device label Kyrios devid 1 transid 38257 /dev/sdb
btrfs: use lzo compression
btrfs: disk space caching is enabled
btrfs bad tree block start 14982790533290893935 20971520
btrfs bad tree block start 15644090216945910062 20971520
btrfs: failed to read chunk root on sdb

mnt-Kyrios.mount mount process exited status=32
failed to mount /mnt/Kyrios defined by systemd
dependency failed for local file systems unit local-fs.target has
failed unit mnt-Kyrios.mount entered failed state.

Useful info:
I am using btrfs-progs 0.20 rc1 and kernel 3.9.2
The whole (1.8TB) disc is pure btrfs with no gpt or other formats like
ext4 is just created by mkfs.btrfs /dev/sdb and all my files are in
subvolumes Root, Media, Home, Opt, etc.

What i did till now was to use wipefs and delete the opensuse and the
dos filesystems that were created by the dd command on top of the pure
btrfs disc. Before i use the wipefs i wasnt able to see sdb btrfs info
at all with blkid command but now i can as can confirm the blkid
output above. At the moment i play with etc/fstab but adding the line:
UUID=b5d84724-f93a-4478-a3eb-3c45c7e5ac72/mnt/Kyriosbtrfs
defaults,compress=lzo01

Or
/dev/sdb /mnt   btrfs   defaults,compress=lzo 0   1

leaves my system unbootable and asks me to see the journalctl

Not sure what i do next. Can anyone spot the error? How can i fix it?


Big headache with lots of valuable data (no i did not use snapper for
backup as was a new disc migration and left it for a month in the back
of my mind:()

Any help will be appreciated.
--
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


Metadata chunk fragmentation?

2013-07-27 Thread Jeremy Atkins
I have a 5 drive btrfs pool that seems to be getting slow

If i start/cancel a rebalance on metadata, it will take 15 to 20
minutes to do 1 chunk, then in dmesg i'll see this:

-mconvert=raid5
[Sat Jul 27 22:16:12 2013] btrfs: relocating block group 18228861403136 flags 20
[Sat Jul 27 22:31:53 2013] btrfs: found 86835 extents
-mconvert=raid1,soft
[Sat Jul 27 22:37:02 2013] btrfs: relocating block group
18230102917120 flags 132
[Sat Jul 27 22:58:16 2013] btrfs: found 88595 extents

My main question I wanted to know is, Should I even care about the
large number of extents, because when I converted all of the metadata
from raid10 to raid1, most of the chunks 100k+ extents. If i should
care, is there a way to defragment the actual chunks?

More info about my system:
kernel 3.9.9-301.fc19.x86_64
dual core 2.2ghz, 4gb ram

$ btrfs fi df /
Data, RAID10: total=3.41TB, used=3.10TB
System, RAID1: total=32.00MB, used=396.00KB
Metadata, RAID1: total=6.00GB, used=4.33GB

$ sudo btrfs fi sh
Label: 'btrfs_tank'  uuid: b0ad55e2-09e0-4658-8cab-d2e11ba03753
Total devices 6 FS bytes used 3.10TB
devid8 size 1.36TB used 1.10TB path /dev/sde1
devid2 size 1.81TB used 1.50TB path /dev/sdd4
devid6 size 1.82TB used 1.56TB path /dev/sdc1
devid5 size 1.36TB used 1.11TB path /dev/sdb1
devid7 size 1.82TB used 1.56TB path /dev/sda1
*** Some devices missing

The missing device... is a different cosmetic problem, happened a long
time ago when I had failing drive, added new drive. did did device
remove, rebooted after it finished and then it started saying
missing...
$ sudo btrfs dev delete missing /
$ dmesg |tail -n1
[1662429.066371] btrfs: no missing devices found to remove
--
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: Recovering from btrfs error Couldn't read chunk root.

2013-07-27 Thread Wang Shilong
Hello, 

It seems Btrfs Chunk Tree is damaged, so you can not mount Btrfs filesystem any 
more.

However, you can try the latest Btrfs-progs, Miao Xie implements chunk tree 
recover function.

The url is:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git


you can try it:
btrfs chunk-recover  -v dev

This is Time-consuming, because it will scan the whole disk. And also,
please catch output of processing(this is helpful to us if the recovery fails, 
-v option
enable this).

Thanks,
Wang






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