ENOSPC during balance
Hallo, I've added a fourth device (/dev/sdf1; connected via USB) to my 3-disks- btrfs bundle (data raid0, metadata raid1), and then I run balance. That needed (for about 6 TByte data) about 17 hours. It finished with ERROR: error during balancing '/srv/MM' - No space left on device There may be more info in syslog - try dmesg | tail The last lines of dmesg: btrfs: found 227973 extents btrfs: relocating block group 26872905728 flags 20 btrfs: found 217765 extents btrfs: relocating block group 22577938432 flags 20 usb 1-1: reset high-speed USB device number 3 using ehci-pci usb 1-1: reset high-speed USB device number 3 using ehci-pci usb 1-1: reset high-speed USB device number 3 using ehci-pci usb 1-1: reset high-speed USB device number 3 using ehci-pci usb 1-1: reset high-speed USB device number 3 using ehci-pci usb 1-1: reset high-speed USB device number 3 using ehci-pci usb 1-1: reset high-speed USB device number 3 using ehci-pci btrfs: found 226454 extents btrfs: relocating block group 21504196608 flags 20 btrfs: found 229068 extents btrfs: relocating block group 4324327424 flags 20 btrfs: found 214531 extents btrfs: relocating block group 20971520 flags 18 btrfs: found 92 extents btrfs: relocating block group 4194304 flags 4 btrfs: 1 enospc errors during balance What does the last line mean? Is there 1 error during the 17 hours of balancing? Or has balance ended with enospc? The actual state: Commands btrfs fi show df Label: 'MM' uuid: 7e94022a-76e7-47f8-954d-1ad69a872bef Total devices 4 FS bytes used 6.10TB devid4 size 1.82TB used 650.03GB path /dev/sdf1 devid3 size 2.73TB used 1.91TB path /dev/sdd devid2 size 1.82TB used 1.68TB path /dev/sdc devid1 size 2.73TB used 1.91TB path /dev/sdb Btrfs Btrfs v0.19 Filesystem 1K-blocks Used Available Use% Mounted on [...] /dev/sdb 9767561292 6554878088 2815565072 70% /srv/MM Viele Gruesse! Helmut -- 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: Best Practice - Partition, or not?
Hallo, Alexander, Du meintest am 01.05.13: If I want to manage a complete disk with btrfs, what's the Best Practice? Would it be best to create the btrfs filesystem on /dev/sdb, or would it be better to create just one partition from start to end and then do mkfs.btrfs /dev/sdb1? Would the same recomendation hold true, if we're talking about huge disks, like 4TB or so? I've tested both versions on a 3 disk bundle of 3 TByte disks (data raid0, meta raid1). mkfs.btrfs ... /dev/sdb /dev/sdc /dev/sdd made some more problems, especially when recognizing or deleting the disk(s). Maybe that's a problem more related to util-linux (especially wipefs and blkid). Partitioning first with gdisk and then mkfs.btrfs ... /dev/sdb1 /dev/sdc1 /dev/sdd1 runs better (perhaps without problems). Viele Gruesse! Helmut -- 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: WARNING: at fs/btrfs/free-space-cache.c:921 __btrfs_write_out_cache+0x6b9/0x9a0 [btrfs]()
Hallo, Alexander, Du meintest am 30.04.13: On my HP Compaq dc5800 with Ubuntu 13.04 and their 3.8.0-19-lowlatency kernel, I've got quite some kernel traces in the syslog. It's a very good idea to use the newest kernel for btrfs. 3.8.0 is really old. Just try kernel 3.8.10. Viele Gruesse! Helmut -- 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-show vs. btrfs different output
Hallo, Jon, Du meintest am 21.03.13: 2. the current git btrfs-show and btrfs fi show both output *different* devices for device with UUID b5dc52bd-21bf-4173-8049-d54d88c82240, and they're both wrong. does blkid output find that uuid anywhere? Since you're working in git, can you maybe do a little bisecting to find out when it changed? Should be a fairly quick test? blkid does /not/ report that uuid anywhere. blkid seems to be a bit clueless. Try file -s instead. Viele Gruesse! Helmut -- 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-show vs. btrfs different output
Hallo, Jon, Du meintest am 21.03.13: First btrfs-show (git): ** ** WARNING: this program is considered deprecated ** Please consider to switch to the btrfs utility btrfs-show makes nasty errors, especially together with blkid. Delete btrfs-show. That's the safe way. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Martin, Du meintest am 05.01.13: No - I don't rely on such an assumption. In the special case I'm just working with I want to use the whole disk only for btrfs. In other cases I work with partitions, and there is just the same problem: at least blkid and findfs don't work when more than 1 device has the same label (p.e. /dev/sda3 and /dev/sdc5). It seems to be a problem which is related to blkid. Helmut, it has been shown here in the thread, that they *do* work in newer versions. If they don?t work for you please compare your version with the ones that do work and file a bug report for your Linux distribution. blkid from util-linux 2.21.2 (libblkid 2.21.0, 25-May-2012 findfs from the same util-linux packet kernel 3.6.11 Is that new enough? --- Reproducable: USB stick with 3 btrfs partitions cold start without stick, logged in as root blkid works Stick inserted: blkid works fdisk -lworks btrfs device scanworks blkid works btrfs-show works blkid hangs blkid /dev/sdb1 works I don't know who may be responsible for this problem - btrfs or blkid or both. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: My usual way: mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... One call for some devices. Wenn I add the option -L mylabel then each device gets the same label, and therefore some other programs can't find the (one) device with the defined label. [...] Especially blkid findfs LABEL=mylabel don't work. How do you mean, don't work? Seems to be a problem which is invoked by btrfs-show. Working with an USB stick (3 btrfs partitions, labelled), working as root, kernel 3.6.11 cold start inserting the stick btrfs device scan ok btrfs fi show ok blkid ok cold start inserting the stick btrfs device scan ok blkid ok btrfs-show ok (?) blkid hangs Maybe the simpliest way is to delete btrfs-show. Viele Gruesse! Helmut -- 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
cleaning old entries
Hallo, linux-btrfs, on my testing USB stick btrfs fi show shows Label: 'mylabel' uuid: e9716633-49f1-44a0-a3b4-90ba9736a540 Total devices 3 FS bytes used 28.00KB devid3 size 1.00GB used 288.00MB path /dev/sdb3 devid2 size 1.00GB used 512.00MB path /dev/sdb2 devid1 size 1.00GB used 292.00MB path /dev/sdb1 Label: 'USBmm' uuid: 43ad1782-5d1c-4211-9333-506bcfdbc3a5 Total devices 1 FS bytes used 28.00KB devid1 size 3.78GB used 423.50MB path /dev/sdb Btrfs Btrfs v0.19 # The problem entry is Label: 'USBmm' It is a remainder of an older experiment, with 2 sticks, configured with mkfs.btrfs -d raid0 -m raid1 -L USBmm /dev/sdb /dev/sdc And at least the label USBmm resides somewhere on the stick where it is hidden from manipulations (except something like dd if=/dev/zero ...) A bit more precisely: the label lies at the beginning of the second 64- kByte block on the stick (may be sector 129). Far away from the other partition data. Contents of /proc/partitions: major minor #blocks name 80 29302560 sda 819775521 sda1 82 369495 sda2 834891792 sda3 84 14265720 sda4 1101048575 sr0 8 163968000 sdb 8 171048576 sdb1 8 181048576 sdb2 8 191048576 sdb3 8 20 821248 sdb4 # -- Output from fdisk -l /dev/sdb: Platte /dev/sdb: 4063 MByte, 4063232000 Byte 125 Köpfe, 62 Sektoren/Spur, 1024 Zylinder, zusammen 7936000 Sektoren Einheiten = Sektoren von 1 ₧ 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x266cff07 Gerät boot. AnfangEnde Blöcke Id System /dev/sdb12048 2099199 1048576 83 Linux /dev/sdb2 2099200 4196351 1048576 83 Linux /dev/sdb3 4196352 6293503 1048576 83 Linux /dev/sdb4 6293504 7935999 821248 83 Linux # -- findfs LABEL=USBmm says unable to resolve 'LABEL=USBmm' - that's ok. And blkid tells nothing about /dev/sdb - that's also ok. -- Has mkfs.btrfs to delete the /dev/sdb data when it overwrites the configuration with data for partitions? Or has the user to run something like dd if=/dev/zero ...? Viele Gruesse! Helmut -- 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: cleaning old entries
Hallo, Jan, Du meintest am 05.01.13: Has mkfs.btrfs to delete the /dev/sdb data when it overwrites the configuration with data for partitions? Or has the user to run something like dd if=/dev/zero ...? Take a look at: https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#How_to_clean_up_o ld_superblock_.3F Thank you - wipefs may help. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Chris, Du meintest am 03.01.13: MBR has no mechanism for labeling the disk itself or the partitions. So /dev/sda cannot have a label or a name. Sure? Yes. MBR itself has no place holder to encode a disk name or partition name. http://en.wikipedia.org/wiki/Master_boot_record I've just played a bit ... btrfs-show tells ** ** WARNING: this program is considered deprecated ** Please consider to switch to the btrfs utility ** Label: USBmm uuid: 43ad1782-5d1c-4211-9333-506bcfdbc3a5 Total devices 1 FS bytes used 28.00KB devid1 size 3.78GB used 423.50MB path /dev/sdb Label: mylabel uuid: e9716633-49f1-44a0-a3b4-90ba9736a540 Total devices 3 FS bytes used 28.00KB devid2 size 1.00GB used 110.38MB path /dev/sdb2 devid1 size 1.00GB used 275.94MB path /dev/sdb1 devid3 size 1.00GB used 263.94MB path /dev/sdb3 Btrfs Btrfs v0.19 # The USBmm entry remains from mkfs.btrfs -d raid0 -m raid1 -L USBmm /dev/sdb Then I run fdisk /dev/sdb and created 4 partitions on /dev/sdb without previous overwriting it with zeros. And then mkfs.btrfs -d raid0 -m raid1 -L mylabel /dev/sdb1 /dev/sdb2 /dev/sdb3 Inspecting the first sectors of /dev/sdb shows the string USBmm at the beginning of the second 64-kByte block (0x10120 ... 0x1012f). The mylabel entries are somewhere after the first 128 kByte. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: [...] And then for blkid: # blkid /dev/sdb: LABEL=test2 UUID=3d5390d0-a41b-4f70-a4e5-b47295d3c717 UUID_SUB=a5bbaa83-6d6f-45dc-9804-9442350c3bc9 TYPE=btrfs /dev/sdc: LABEL=test2 UUID=3d5390d0-a41b-4f70-a4e5-b47295d3c717 UUID_SUB=01e0bc77-cfdf-4bd7-bfd3-05e14affa66a TYPE=btrfs Strange - in another way. Here blkid (without any device) hangs. See the attachment (strace blkid). Additional: Working as root: blkid hangs (at least sometimes). Working as underprivileged user: /sbin/blkid shows many informations (and doesn't hang). But it doesn't show the btrfs devices/partitions. /sbin/blkid /dev/sdb shows the btrfs label. Maybe it's mostly or only a blkid problem - I'll subscribe the util- linux mailinglist. Viele Gruesse! Helmut -- 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
Option LABEL
Hallo, linux-btrfs, please delete the option -L (for labelling) in mkfs.btrfs, in some configurations it doesn't work as expected. My usual way: mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... One call for some devices. Wenn I add the option -L mylabel then each device gets the same label, and therefore some other programs can't find the (one) device with the defined label. Especially blkid findfs LABEL=mylabel don't work. file -s /dev/sdb (etc.) shows the label (and the problem). Other tries: mkfs.btrfs -L mylabel /dev/sdb creates a new btrfs filesystem and overwrites prior tries. What works: btrfs filesystem label /dev/sdb mylabel Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: please delete the option -L (for labelling) in mkfs.btrfs, in some configurations it doesn't work as expected. My usual way: mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... One call for some devices. Wenn I add the option -L mylabel then each device gets the same label, and therefore some other programs can't find the (one) device with the defined label. I'm sure we've been over this territory before. Devices are not labelled; filesystems are labelled. You are labelling the whole filesystem, which exists over several devices, so the same label will be attached to every device in the filesystem. But for what purpose offers mkfs.btrfs this option? Especially blkid findfs LABEL=mylabel don't work. How do you mean, don't work? What are they showing, and what do you think should they be showing? Without this double-labelled (?) devices blkid shows all devices with (if defined) their labels. When I define the same label for more than 1 device (btrfs or ext2fs or ...) then blkid shows nothing. No output for any of the devices. findfs: with double-labelled devices findfs doesn't find any label. It looks like both of them print an arbitrary device node of the devices that the FS lives on. Given that both of these tools probably expect a one-to-one relationship between a block device and a filesystem, this is not unreasonable. May be that this is not unreasonable. But when mkfs.btrfs offers the label option I don't expect this behaviour. I had mentioned this problem more than a year ago, it still exists. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: But for what purpose offers mkfs.btrfs this option? So that you don't have to run the label command immediately after making the filesystem. Most mkfs implementations for different filesystems have something similar, usually with the -L option. But other filesystems don't put the label onto more than 1 device. There's the problem for/with btrfs. The label has to be unique for the whole machine. Without this double-labelled (?) devices blkid shows all devices with Double-labelled? The filesystem has one label, belonging to the filesystem. I don't see where the double-labelling comes in. As I described: mkfs.btrfs -d raid0 -m raid1 -l mylabel /dev/sdb /dev/sdc /dev/sdd labels all three devices with the same name, and then programs like blkid or findfs don't find any label (for all labelled devices, not only for btrfs devices). And as I have written before: file -s /dev/sdb file -s /dev/sdc file -s /dev/sdd shows for each of these devices the same label. -- When I run mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd and then btrfs filesystem label /dev/sdb mylabel then only /dev/sdb shows this label (as long as none of the 3 devices is mounted). When I then run mount LABEL=mylabel /mnt/btr then all works fine. And then (after mounting) blkid /dev/sdb blkid /dev/sdc blkid /dev/sdd show the same label. blkid without any device seems to hang - may be I haven't waited long enough. (if defined) their labels. When I define the same label for more than 1 device (btrfs or ext2fs or ...) then blkid shows nothing. No output for any of the devices. This is a fault in the version of blkid you're running, then. here: blkid from until-linux 2.21.2 (libblkid 2.21.0, 25-May-2012). And older versions. There's nothing to stop me from labelling two ext2 filesystems with the same label. That part is right: I can label more than 1 device with the same name, not only under btrfs. But then (I had written this problem) programs like blkid don't find any labelled device. If blkid can't handle that, then it's got problems beyond btrfs. On my main machine, it seems to work correctly: $ sudo blkid /dev/sda: LABEL=media UUID=3993e50e-a926-48a4-867f-36b53d924c35 UUID_SUB=5fd56eec-5e26-4c1f-a02a-f86550e4aefe TYPE=btrfs /dev/sdc: LABEL=media UUID=3993e50e-a926-48a4-867f-36b53d924c35 UUID_SUB=4e392bea-f39a-4cba-b78c-c712479bf3f0 TYPE=btrfs /dev/sde: LABEL=media UUID=3993e50e-a926-48a4-867f-36b53d924c35 UUID_SUB=5e2555bd-bf36-430b-af5a-aa81604afc96 TYPE=btrfs /dev/sdp: LABEL=media UUID=3993e50e-a926-48a4-867f-36b53d924c35 UUID_SUB=404d13f5-0231-46db-a311-ad7a4f99eef3 TYPE=btrfs /dev/sdr: LABEL=media UUID=3993e50e-a926-48a4-867f-36b53d924c35 UUID_SUB=90469059-f012-4b6e-9233-8c591cbeaa80 TYPE=btrfs /dev/sdq: LABEL=media UUID=3993e50e-a926-48a4-867f-36b53d924c35 UUID_SUB=646d3d32-5193-4fcd-afb2-43f14122a149 TYPE=btrfs /dev/sds: LABEL=media UUID=3993e50e-a926-48a4-867f-36b53d924c35 UUID_SUB=f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1 TYPE=btrfs Is media mounted? My blkid version: blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011) It's older than my actual version, but I had found this problem more than a year ago. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, cwillu, Du meintest am 03.01.13: But other filesystems don't put the label onto more than 1 device. There's the problem for/with btrfs. Other filesystems don't exist on more than one device, so of course they don't put a label on more than one device. Yes, I know. And let me repeat the problem: programs like blkid don't work if more than 1 device has the same label. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: But for what purpose offers mkfs.btrfs this option? So that you don't have to run the label command immediately after making the filesystem. But other filesystems don't put the label onto more than 1 device. There's the problem for/with btrfs. Aargh. How many times do I have to say this? Devices are not given labels. *Filesystems* are given labels. And mkfs.btrfs combines working with devices and working with a filesystem. blkid /dev/sdb shows (if set) the label of a device (among other data). The label has to be unique for the whole machine. Wrong. You can have several filesystems on a machine with the same label. On my machines that doesn't work when I use programs like blkid or findfs. They don't work when there is more than 1 device with the same label. That's no special btrfs problem, that happens with (p.e.) ext4fs too. It doesn't mean that they're easily managable, but there's nothing that will stop it from happening. If you want a unique label for a *device*, take a look at the symlinks in /dev/disk/by-id, and the udev rules that generate them. Sorry - I don't use udev (I've told it long time ago). And I still believe that btrfs doesn't depend on udev. Trying to use filesystem labels to give unique and stable device IDs is the wrong tool for the job. I beg to differ. On my machines it's the simpliest way, and it's a sure way. [...] As I said above, you're expecting something which just isn't true. Filesystems have labels, not devices. If you want to have unique labels on devices, then you're going to have to write some udev rules to generate them for you, and then refer to /dev/helmuts-devices/foo (or whatever you want to call them). And how is the way for a system which doesn't use udev? Labelling via btrfs filesystem label device label works well. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Chris, Du meintest am 03.01.13: Device can mean more than one thing, physical device, partition, md device, logical volume, etc. Label is more narrowly defined to that of filesystems. MBR has no mechanism for labeling the disk itself or the partitions. So /dev/sda cannot have a label or a name. Sure? btrfs filesystem label /dev/sdb mylabel works, and then btrfs filesystem label /dev/sdb shows mylabel. Also: findfs LABEL=mylabel shows /dev/sdb blkid /dev/sdb shows (among other data) LABEL=mylabel Except for the btrfs command: same behaviour as with other filesystems. Especially with CDs and DVDs (which normally don't use partitions). Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: [...] Trying to use filesystem labels to give unique and stable device IDs is the wrong tool for the job. I beg to differ. On my machines it's the simpliest way, and it's a sure way. No, because *it* *doesn't* *work*. This is not a bug. This is how things have always behaved -- you're relying on an assumption (one FS per device) which simply isn't true any longer. No - I don't rely on such an assumption. In the special case I'm just working with I want to use the whole disk only for btrfs. In other cases I work with partitions, and there is just the same problem: at least blkid and findfs don't work when more than 1 device has the same label (p.e. /dev/sda3 and /dev/sdc5). And how is the way for a system which doesn't use udev? There isn't one ready-made. Your options are: * run udev * write something which uses (e.g.) SMART information on block devices to extract a unique ID, and convert that into a stable device label (which is effectively what udev does) Sorry - I don't need the unique ID for the machines. I can use (p.e.) e2label /dev/sda3 Var for labelling an ext2/3/4 partition. Works like a charm, especially for USB disks. * find some piece of the device which isn't going to be overwritten by partition tables, GPTs, filesystems, or other kinds of metadata,and write your label into there; again, you will need to developyour own tool for reading/writing this information Sorry - that's not necessary. When I connect the disk then I can search with findfs without having mounted any partition. Labelling via btrfs filesystem label device label works well. Clearly it doesn't, because you're having problems with it. No - not at all! I've only problems when I use the -L option of mkfs.btrfs together with more than 1 device in the mkfs.btrfs command. The behaviour where only one device in the FS gets the label, immediately after a btrfs label command, is a bug -- *all* of the devices in the FS should get the label. You're trying to rely on the behaviour of a bug, not on the designed behaviour of the system. What works: Building the filesystem with mkfs.btrfs, without the -L option Then (p.e.) btrfs filesystem label device label (unmounted system) Then I can check the existence (not only for btrfs formatted disks) with findfs LABEL=label mount LABEL=label mountpoint As mentioned: works not only with btrfs, works fine especially for USB disks. I don't need any UUID etc. for this way of identyfying. I don't need to change the mount directive when I change a smaller disk to a bigger disk. Viele Gruesse! Helmut -- 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: Option LABEL
Hallo, Chris,
Du meintest am 03.01.13:
So 'btrfs fi label' relabeling with an unmounted system changes the
file system label metadata on all member devices, according to btrfs
fi label. Now when I use file:
On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd)
btrfs fi label /dev/sdb mylabel
only sets the label on the (unmounted) device /dev/sdb. /dev/sdc and
/dev/sdd remain without label.
# file -s /dev/sdb
/dev/sdb: BTRFS Filesystem (label test2, sectorsize 4096, nodesize
4096, leafsize 4096)
# file -s /dev/sdc
/dev/sdc: BTRFS Filesystem (label test2, sectorsize 4096, nodesize
4096, leafsize 4096)
Again it correctly reports the label, even though I had only changed
the label on sdc (which actually is improper language, I changed the
label on the file system implied by device sdc which also extends to
device sdb).
Strange.
Actually the btrfs system is mounted and has to run a job with needs
about 5 days - I may not stop it.
But before the first mounting of the system only /dev/sdb showed the
label. Maybe with the first mounting the label spreads over all disks.
And then for blkid:
# blkid
/dev/sdb: LABEL=test2 UUID=3d5390d0-a41b-4f70-a4e5-b47295d3c717
UUID_SUB=a5bbaa83-6d6f-45dc-9804-9442350c3bc9 TYPE=btrfs
/dev/sdc: LABEL=test2 UUID=3d5390d0-a41b-4f70-a4e5-b47295d3c717
UUID_SUB=01e0bc77-cfdf-4bd7-bfd3-05e14affa66a TYPE=btrfs
Strange - in another way.
Here blkid (without any device) hangs. See the attachment (strace
blkid).
Viele Gruesse!
Helmut
execve(/sbin/blkid, [blkid], [/* 47 vars */]) = 0
brk(0) = 0x805
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40024000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=55572, ...}) = 0
mmap2(NULL, 55572, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000
close(3)= 0
open(/lib/libblkid.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0A\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=163440, ...}) = 0
mmap2(NULL, 162160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x40033000
mmap2(0x40059000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26) = 0x40059000
close(3)= 0
open(/lib/libuuid.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\16\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=13244, ...}) = 0
mmap2(NULL, 16004, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x4005b000
mmap2(0x4005e000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x4005e000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\227\1\0004\0\0\0..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1790836, ...}) = 0
mmap2(NULL, 1591836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x4005f000
mprotect(0x401dd000, 4096, PROT_NONE) = 0
mmap2(0x401de000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17e) = 0x401de000
mmap2(0x401e1000, 10780, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401e1000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401e4000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401e5000
set_thread_area({entry_number:-1 - 6, base_addr:0x401e4bc0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0x401de000, 8192, PROT_READ) = 0
mprotect(0x40021000, 4096, PROT_READ) = 0
munmap(0x40025000, 55572) = 0
brk(0) = 0x805
brk(0x8071000) = 0x8071000
getuid32() = 0
geteuid32() = 0
getgid32() = 0
getegid32() = 0
prctl(PR_GET_DUMPABLE) = 1
getuid32() = 0
geteuid32() = 0
getgid32() = 0
getegid32() = 0
prctl(PR_GET_DUMPABLE) = 1
open(/etc/blkid.conf, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open(/run/blkid/blkid.tab, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1212, ...}) = 0
fcntl64(3, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=1212, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40025000
_llseek(3, 0, [0], SEEK_CUR)= 0
read(3, device DEVNO=\0x0801\ TIME=\135..., 4096)
Re: Option LABEL
Hallo, Hugo,
Du meintest am 03.01.13:
On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd)
btrfs fi label /dev/sdb mylabel
only sets the label on the (unmounted) device /dev/sdb. /dev/sdc
and /dev/sdd remain without label.
This is a bug.
Hmmm - I'll test it on another system.
Strange - in another way.
Here blkid (without any device) hangs. See the attachment (strace
blkid).
[snip]
stat64(/dev/fd0, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0),
...}) = 0 open(/dev/fd0, O_RDONLY|O_LARGEFILE) = 4
fadvise64_64(4, 0, 0, POSIX_FADV_RANDOM) = 0
fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0
uname({sys=Linux, node=izar, ...}) = 0
ioctl(4, BLKGETSIZE64, 0x8050d5c) = 0
_llseek(4, 0, [0], SEEK_SET)= 0
read(4, 0x80517a4, 1024)= -1 EIO (Input/output
error) _llseek(4, 0, [0], SEEK_SET)= 0
read(4, 0x80517a4, 1024)= -1 EIO (Input/output
error) _llseek(4, 0, [0], SEEK_SET)= 0
read(4, 0x80517a4, 1024)= -1 EIO (Input/output
error) _llseek(4, 0, [0], SEEK_SET)= 0
read(4, 0x80517a4, 1024)= -1 EIO (Input/output
error) _llseek(4, 0, [0], SEEK_SET)= 0
read(4, 0x80517a4, 1024)= -1 EIO (Input/output
error) _llseek(4, 0, [0], SEEK_SET)= 0
read(4, 0x80517a4, 1024)= -1 EIO (Input/output
error) _llseek(4, 0, [0], SEEK_SET)= 0
read(4, 0x80517a4, 1024)= -1 EIO (Input/output
error) _llseek(4, 0, [0], SEEK_SET)= 0
read(4, unfinished ...
This is waiting for /dev/fd0 to return some data. I guess it'll
give up after a few times round (8? 10?) and return some results.
I've waited 10 minutes ...
I know a similar behaviour p.e. when I run
btrfs-show
Then btrfs seems to test all block devices in /dev (no udev system)
and then tells most times
failed to read /dev/nonexistent device: No such device or address
But those (unnecessary) messages come quick, with only some seconds
delay.
-
The above log file comes from a machine without floppy disk (a laptop).
Running blkid on an elder tower (with installed and usable floppy
disk) also checks for /dev/fd0 and then tells ok.
Tomorrow I'll test this behaviour on another laptop. Could be a blkid
error.
Viele Gruesse!
Helmut
--
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: filesystem show still has stale filesystem
Hallo, Florian, Du meintest am 05.08.12: I was playing with btrfs and accidentally formatted the disk directly (/dev/sdb instead of sdb1). Since then I rewrote the GPT partition table, recreated the partition and ran btrfs device scan. Still, btrfs filesystem show prints: root@horus /mnt # btrfs fi sh --all-devices failed to read /dev/sr0: No medium found Label: 'test' uuid: ffab72f2-eff1-4ac8-a694-d56dd84fda24 Total devices 1 FS bytes used 28.00KB devid1 size 2.73TB used 2.04GB path /dev/sdb Label: 'home' uuid: c465d715-098a-4d0d-bebc-6aa51f4cb349 Total devices 1 FS bytes used 28.00KB devid1 size 2.73TB used 2.04GB path /dev/sdb1 formatting leaves most bytes on the disk untouched. If you really want to use only /dev/sdb (or only /dev/sdb1) then you should first fill many bytes at the beginning of the disk with zeros. Some months ago someone had told the minimum; I have forgotten this value. But something like dd if=/dev/zero of=/dev/sdb bs=1M count=10 should do the job. And then mkfs.btrfs creates the (only) wanted partition(s). Viele Gruesse! Helmut -- 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: severe hardlink bug
Hallo, Arnd, Du meintest am 30.07.12: btrfs only fails when you have hundreds of hardlinks to the same file in the *same* directory ... certainly not a standard use case. Actually, hundreds of hardlinks is certainly over optimistic. In my testing 15 links in the same directory were enough to get the Too many links error. It depends on the length of the file name of the hardlinks. And then I may get problems with my favourite backup program rsnapshot; it uses hard links, and my backups often have more than 20 hard links to 1 file. Sometimes about 80 characters long. Viele Gruesse! Helmut -- 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: bug: raid10 filesystem has suddenly ceased to mount
Hallo, , Du meintest am 14.07.12: The problem is that the BTRFS raid10 filesystem without any understandable cause refuses to mount. Here is dmesg output: [77847.845540] device label linux-btrfs-raid10 devid 3 transid 45639 /dev/sdc1 [77848.633912] btrfs: allowing degraded mounts [77848.633917] btrfs: enabling auto defrag [77848.633919] btrfs: use lzo compression [77848.633922] btrfs: turning on flush-on-commit [77848.658879] parent transid verify failed on 2363592273920 wanted 31596 found 25250 [77848.659060] parent transid verify failed on 2363592273920 wanted 31596 found 25250 [...] Sounds familiar ... Re-install your backup. Viele Gruesse! Helmut -- 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: Strange directories in /
Hallo, Markus, Du meintest am 01.07.12: I am running btrfs for a few months now. I just realized that I have a few strange directories in / % ls / -1 ? ???J?? Q??? PL PR bin boot dev etc home lib lib32 lib64 lost+found media mnt opt proc p?c'?? root run sbin sys tmp usr var ?? Is this a known problem? I have absolutely no idea where these directories come from. That are no (real) directories, that is a damaged file system. Look for your backup. Viele Gruesse! Helmut -- 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: R: Re: Subvolumes and /proc/self/mountinfo
Hallo, Goffredo, Du meintest am 20.06.12: [...] Am not saying that we *should* move the kernel away from /boot. I am only saying that having the kernel near /lib/modules *has* some advantages. Few year ago there are some gains to have a separate /boot (ah, the time when the bios were unable to address the bigger disk), where there are the minimum things to bootstrap the system. Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ? Where is the big problem? I use separate subdirectories for different kernels, p.e. /boot/ 2.6.38.4 or /boot/3.3.4 or /boot/3.3.4-big. And these subdirs contain (p.e.) .config, vmlinuz, initrd, System.map. It's a very clear design. No incredibly long filenames. Viele Gruesse! Helmut -- 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: Subvolumes and /proc/self/mountinfo
Hallo, Chris, Du meintest am 19.06.12: I'm trying to figure out an algorithm from taking an arbitrary mounted btrfs directory and break it down into: device(s), subvolume, subpath where, keep in mind, subpath may not actually be part of the mount. Do you want an API for this, or is it enough to wander through /dev/disk style symlinks? The big reason it isn't here yet is because Kay had this neat patch to blkid and udev to just put all the info you need into /dev/btrfs (or some other suitable location). It would allow you to see which devices belong to which filesystems etc. btrfs should work even without any udev installation. Viele Gruesse! Helmut -- 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: Uncorrectable errors on newly extended volume
Hallo, Randall, Du meintest am 07.06.12: [...] I've just upgraded to 3.4.0 from git.kernel.org and I'm still running into problems. I checked the Problems FAQ and there doesn't seem to be anything that matches my problem. [...] Any more help would be appreciated. Why is this happening, and how can I get my data back? Why? I don't know - sorry. Data back: take your last backup. (I know this way to get my data back ...) btrfs is still under heavy construction, and restoring damaged data is still a problematic work. You always should have a valid backup (better: some backups). Viele Gruesse! Helmut -- 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: New btrfs-progs integration branch
Hallo, Hugo, Du meintest am 05.06.12: The branch is fetchable with git from: http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605 There seems to be a bug inside: [...] gcc -g -O0 -o btrfsck btrfsck.o ctree.o disk-io.o radix-tree.o extent- tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o repair.o -luuid gcc -g -O0 -o btrfs-convert ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o repair.o convert.o -lext2fs -lcom_err -luuid gcc convert.o -o convert convert.o: In function `btrfs_item_key': /tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to `read_extent_buffer' convert.o: In function `btrfs_dir_item_key': /tmp/btrfs-progs-unstable/ctree.h:1437: undefined reference to `read_extent_buffer' convert.o: In function `btrfs_del_item': [...] Viele Gruesse! Helmut -- 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: New btrfs-progs integration branch
Hallo, Hugo, Du meintest am 06.06.12: However, the third line with the problem looks like something out of date. Possibly a mis-merge? Where should I search? Viele Gruesse! Helmut -- 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: New btrfs-progs integration branch
Hallo, Hugo, Du meintest am 06.06.12: git checkout integration-20120605 [...] Can you compare your Makefile with the one at [1] -- in particular the progs variable at line 21-23, the all target on line 37, and the btrfs-convert target on line 97. There definitely should not be a plain convert target in there, but that seems to be what your system was failing on. Makefile with 3888 Bytes. md5sum Makefile shows (my file) deef961e3ecd560ad8710cf0b58f5570 Makefile (the file from your link) deef961e3ecd560ad8710cf0b58f5570 Makefile The problem is somewhere on another place ... Viele Gruesse! Helmut -- 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: New btrfs-progs integration branch
Hallo, Hugo, Du meintest am 06.06.12: The branch is fetchable with git from: http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605 gcc convert.o -o convert convert.o: In function `btrfs_item_key': /tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to `read_extent_buffer' convert.o: [...] Solved - thanks for your help! You have changed the Makefile; make convert does not more work, it has changed to make btrfs-convert --- You can find the slackware binary at http://helmut.hullen.de/filebox/Linux/slackware/ap/btrfs-progs-20120606-i486-1hln.txz Viele Gruesse! Helmut -- 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: Help with data recovering
Hallo, Martin, Du meintest am 05.06.12: --super works but my root tree 2 has many errors too. What can I do next? Have a data recovery company try to physically recover the bad harddisk to a good one About 1 year ago I asked Kroll-Ontrack. They told me they couldn't (yet) recover btrfs. Maybe not only time has changed ... Viele Gruesse! Helmut -- 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: delete disk proceedure
Hallo, Jim, Du meintest am 05.06.12: /dev/sda 11T 4.9T 6.0T 46% /btrfs [root@advanced ~]# btrfs fi show failed to read /dev/sr0 Label: none uuid: c21f1221-a224-4ba4-92e5-cdea0fa6d0f9 Total devices 12 FS bytes used 4.76TB devid6 size 930.99GB used 429.32GB path /dev/sdf devid5 size 930.99GB used 429.32GB path /dev/sde devid8 size 930.99GB used 429.32GB path /dev/sdh devid9 size 930.99GB used 429.32GB path /dev/sdi devid4 size 930.99GB used 429.32GB path /dev/sdd devid3 size 930.99GB used 429.32GB path /dev/sdc devid 11 size 930.99GB used 429.08GB path /dev/sdk devid2 size 930.99GB used 429.32GB path /dev/sdb devid 10 size 930.99GB used 429.32GB path /dev/sdj devid 12 size 930.99GB used 429.33GB path /dev/sdl devid7 size 930.99GB used 429.32GB path /dev/sdg devid1 size 930.99GB used 429.09GB path /dev/sda Btrfs v0.19-35-g1b444cd df -h and btrfs fi show seem to be in good size agreement. Btrfs was created as raid1 metadata and raid0 data. I would like to delete the last 4 drives leaving 7T of space to hold 4.9T of data. My plan would be to remove /dev/sdi, j, k, l one at a time. After all are deleted run btrfs fi balance /btrfs. I'd prefer btrfs device delete /dev/sdi btrfs filesystem balance /btrfs btrfs device delete /dev/sdj btrfs filesystem balance /btrfs etc. - after every delete its balance run. That may take a lot of hours - I use the last lines of dmesg to extrapolate the needed time (btrfs produces a message about every minute). And you can't use the console from where you have started the balance command. Therefore I wrap this command: echo 'btrfs filesystem balance /btrfs' | at now Viele Gruesse! Helmut -- 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: delete disk proceedure
Hallo, Hugo, Du meintest am 05.06.12: [...] And you can't use the console from where you have started the balance command. Therefore I wrap this command: echo 'btrfs filesystem balance /btrfs' | at now ... or just put it into the background with btrfs bal start /mountpoint . You know, like everyone else does. :) I know that possibility too. My proposal puts every message (normal messages and error messages) into a mail to root (when root has started this command). Viele Gruesse! Helmut -- 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: Uncorrectable errors on newly extended volume
Hallo, Randall, Du meintest am 01.06.12: I'm having a problem with a newly extended btrfs volume. It is running on debian testing with an almost stock 3.1.0 kernel with a little bit of patches You should use a newer kernel, p.e. 3.3.7 or 3.4 Viele Gruesse! Helmut -- 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
feature request (was: kernel 3.3.4 damages filesystem (?))
Hallo, Martin, Du meintest am 10.05.12: [...] Maybe we should evaluate the possiblility of such a one file gets on one disk feature. Helmut Hullen has the use case: Many disks, totally non-critical but nice-to-have data. If one disk dies, some *files* should lost, not some *random parts of all files*. This could be accomplished by some userspace-tool that moves stuff around, combined with file pinning-support, that lets the user make sure a specific file is on a specific disk. Yeah, basically I think thats the whole point Helmut is trying to make. Yes - that's the feature which I miss ... I am not sure whether that should be in userspace. It could be just an allocation mode like raid0 or single. Such as single as in one file is really on one disk and thats it. What I'm dreaming for: I have a bundle/cluster of (p.e.) 3 disks. When I remove 1 disk (accidently/planned/because of disk failure) then I'd be very pleased when the contents of the other disks is (mostly) still readable. It's no fun restoring Terabytes ... Yes - I know: that's no backup, that doesn't replace a backup. Viele Gruesse! Helmut -- 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
failed disk (was: kernel 3.3.4 damages filesystem (?))
Hallo, Hugo, Du meintest am 07.05.12: mkfs.btrfs -m raid1 -d single should give you that. What's the difference to mkfs.btrfs -m raid1 -d raid0 - RAID-0 stripes each piece of data across all the disks. - single puts data on one disk at a time. [...] In fact, this is probably a good argument for having the option to put back the old allocator algorithm, which would have ensured that the first disk would fill up completely first before it touched the next one... The actual version seems to oscillate from disk to disk: Copying about 160 GiByte shows Label: none uuid: fd0596c6-d819-42cd-bb4a-420c38d2a60b Total devices 2 FS bytes used 155.64GB devid2 size 136.73GB used 114.00GB path /dev/sdl1 devid1 size 68.37GB used 45.04GB path /dev/sdk1 Btrfs Btrfs v0.19 Watching the amount showed that both disks are filled nearly simultaneously. That would be more difficult to restore ... Viele Gruesse! Helmut -- 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
failed disk (was: kernel 3.3.4 damages filesystem (?))
Hallo, Hugo, Du meintest am 07.05.12: [...] With a file system like ext2/3/4 I can work with several directories which are mounted together, but (as said before) one broken disk doesn't disturb the others. mkfs.btrfs -m raid1 -d single should give you that. Just a small bug, perhaps: created a system with mkfs.btrfs -m raid1 -d single /dev/sdl1 mount /dev/sdl1 /mnt/Scsi btrfs device add /dev/sdk1 /mnt/Scsi btrfs device add /dev/sdm1 /mnt/Scsi (filling with data) and btrfs fi df /mnt/Scsi now tells Data, RAID0: total=183.18GB, used=76.60GB Data: total=80.01GB, used=79.83GB System, DUP: total=8.00MB, used=32.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=192.74MB Metadata: total=8.00MB, used=0.00 -- Data, RAID0 confuses me (not very much ...), and the system for metadata (RAID1) is not told. Viele Gruesse! Helmut -- 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: failed disk
Hallo, Hugo, Du meintest am 09.05.12: mkfs.btrfs -m raid1 -d single should give you that. Just a small bug, perhaps: created a system with mkfs.btrfs -m raid1 -d single /dev/sdl1 mount /dev/sdl1 /mnt/Scsi btrfs device add /dev/sdk1 /mnt/Scsi btrfs device add /dev/sdm1 /mnt/Scsi (filling with data) and btrfs fi df /mnt/Scsi now tells Data, RAID0: total=183.18GB, used=76.60GB Data: total=80.01GB, used=79.83GB System, DUP: total=8.00MB, used=32.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=192.74MB Metadata: total=8.00MB, used=0.00 -- Data, RAID0 confuses me (not very much ...), and the system for metadata (RAID1) is not told. DUP is two copies of each block, but it allows the two copies to live on the same device. It's done this because you started with a single device, and you can't do RAID-1 on one device. The first bit of metadata you write to it should automatically upgrade the DUP chunk to RAID-1. Ok. Sounds familiar - have you explained that to me many months ago? As to the spurious upgrade of single to RAID-0, I thought Ilya had stopped it doing that. What kernel version are you running? 3.2.9, self made. I could test the message with 3.3.4, but not today (if it's only an interpretation of always the same data). Out of interest, why did you do the device adds separately, instead of just this? a) making the first 2 devices: I have tested both versions (one line with 2 devices or 2 lines with 1 device); no big difference. But I had tested the option -L (labelling) too, and that makes shit for the oneliner: both devices get the same label, and then findfs finds none of them. The really safe way would be: deleting this option for the mkfs.btrfs command and only using btrfs fi label device [newlabel] b) third device: that's my usual test: make a cluster of 2 deivces fill them with data add a third device delete the smallest device Viele Gruesse! Helmut -- 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: failed disk
Hallo, Hugo, Du meintest am 09.05.12: As to the spurious upgrade of single to RAID-0, I thought Ilya had stopped it doing that. What kernel version are you running? 3.2.9, self made. OK, I'm pretty sure that's too old -- it will upgrade single to RAID-0. You can probably turn it back to single using balance filters: # btrfs fi balance -dconvert=single /mountpoint (You may want to write at least a little data to the FS first -- balance has some slightly odd behaviour on empty filesystems). manana ... the system is just running balance after device delete. And that may still need 4 ... 5 hours. Out of interest, why did you do the device adds separately, instead of just this? a) making the first 2 devices: I have tested both versions (one line with 2 devices or 2 lines with 1 device); no big difference. But I had tested the option -L (labelling) too, and that makes shit for the oneliner: both devices get the same label, and then findfs finds none of them. Umm... Yes, of course both devices will get the same label -- you're labelling the filesystem, not the devices. (Didn't we have this argument some time ago?). Not with that special case (and that led me to misinterpreting the error ...). I don't know what findfs is doing, that it can't find the filesystem by label: you may need to run sync after mkfs, possibly. No - findfs works quite simple: if it finds 1 label then it tells the partition. If it finds more or less labels it tells nothing. b) third device: that's my usual test: make a cluster of 2 deivces fill them with data add a third device delete the smallest device What are you testing? And by delete do you mean btrfs dev delete or pull the cable out? First pure software delete. Tomorrow I'll reboot the system and look at the results with btrfs fi show It should tell only 2 devices (that's the part which seems to work as described at least since kernel 3.2). By the way: it seems to be necessary running btrfs fi balance ... after btrfs device add ... and after btrfs device delete Viele Gruesse! Helmut -- 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: failed disk
Hallo, Hugo, Du meintest am 09.05.12: btrfs fi df /mnt/Scsi now tells Data, RAID0: total=183.18GB, used=76.60GB Data: total=80.01GB, used=79.83GB System, DUP: total=8.00MB, used=32.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=192.74MB Metadata: total=8.00MB, used=0.00 -- Data, RAID0 confuses me (not very much ...), and the system for metadata (RAID1) is not told. DUP is two copies of each block, but it allows the two copies to live on the same device. It's done this because you started with a single device, and you can't do RAID-1 on one device. The first bit of metadata you write to it should automatically upgrade the DUP chunk to RAID-1. It has done - ok. Adding and removing disks/partitions works as expected. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Martin, Du meintest am 08.05.12: No - since some years I use a kind of outsourced backup. A copy of all data is on a bundle of disks somewhere in the neighbourhood. As mentionend: the data isn't business critical, it's just nice to have. It's not worth something like raid1 or so (with twice the costs of a non raid solution). Thats not true when you use BTRFS RAID1 with three disks. BTRFS will only store each chunk on two different drives then, not on all three. Such it is not twice the cost, but given all three drives have the same capacity about one and a half times the cost. Consider the time to recover the files from the outsourced backup. Maybe it does make up the money you would have to spend for one additional harddisk. I have considered it, many times. And the result is unchanged: no RAID1. It doesn't replace a real backup. Anyway, I agree with the others responding to your post that this one harddisk died and I do not see a kernel version related issue. Any striped RAID 0 would have failed in that case. Yes - I had written yesterday that the disk is dead. One of three disks. I'm on the way restoring (from backup) the three disks. And you can use three BTRFS filesystems the same way as three Ext4 filesystems if you prefer such a setup if the time spent for restoring the backup does not make up the cost for one additional disk for you. But where's the gain? If a disk fails I have a lot of tools for repairing an ext2/3/4 system. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Fajar, Du meintest am 08.05.12: And you can use three BTRFS filesystems the same way as three Ext4 filesystems if you prefer such a setup if the time spent for restoring the backup does not make up the cost for one additional disk for you. But where's the gain? If a disk fails I have a lot of tools for repairing an ext2/3/4 system. It won't work if you use it in RAID0 (e.g. with LVM spanning three disks, then use ext4 on top of the LV). But when I use ext2/3/4 I neither need RAID0 nor do I need LVM. As others said, if your only concern is if a disk is dead, I want to be able to access data on other disks, then simply use btrfs as three different fs, mounted on three directories. But then I don't need especially btrfs. btrfs will shine when: - you need checksum and self-healing in raid10 mode - you have lots of small files - you have highly compressible content - you need snapshot/clone feature For my video collection (mpeg2) nothing fits ... The only advantage I see with btrfs is adding a bigger disk deleting/removing a smaller disk with really simple commands. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Clemens, Du meintest am 08.05.12: But where's the gain? If a disk fails I have a lot of tools for repairing an ext2/3/4 system. Nope, when a disk in your ext4 raid0 array fails, you are just as doomed. Why should I use RAID0 with a bundle of ext2/3/4? Mounting on/in the directory tree does the job. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Felix, Du meintest am 08.05.12: Why should I use RAID0 with a bundle of ext2/3/4? Mounting on/in the directory tree does the job. Nobody told you that you should do it. What EVERYBODY here is telling you: The problem you have right now would be the same damn problem, no matter what fs you would you. Every fs will be unusable if you lose one disk in a raid0 setup. That's all what we are trying to tell you for the last 15 mails :) If you don't see any benefits using btrfs then simply don't use it I still hope for a benefit when I use btrfs. As I've written many times: I want a system for my video collection which allows adding a bigger disk deleting/removing a smaller disk with simple commands. btrfs seems to be able to do that (and I have tested this job many times). But with my configuration mkfs.btrfs -m raid1 -d raid0 I've (again) seen that all data vanishes when 1 disk fails. I'll try Hugo's proposal mkfs.btrfs -m raid1 -d single. And I hope that it doesn't make all disks unreadable when 1 disk fails. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Felix, Du meintest am 08.05.12: As I've written many times: I want a system for my video collection which allows adding a bigger disk deleting/removing a smaller disk with simple commands. btrfs seems to be able to do that (and I have tested this job many times). But with my configuration mkfs.btrfs -m raid1 -d raid0 I've (again) seen that all data vanishes when 1 disk fails. I'll try Hugo's proposal mkfs.btrfs -m raid1 -d single. And I hope that it doesn't make all disks unreadable when 1 disk fails. [...] @-d single Is it really possible to remove a disk from btrfs (created with -d single) without losing the data on that disk? When the system is configured with mkfs.btrfs -m raid1 -d raid0 then the above shown way is possible, it works (now) as expected. Ok - it needs some time. And I have yet told in this mailing list that I'll try the option 2-d single. Is there a way to tell balance to copy all the data from this disk to the other disks (ofc if there is enough free space on them)? As I've written some hours ago: I run btrfs fi balance ... after adding and after deleting a disk. Maybe it's not necessary. Especially it seems not to be necessary after adding a disk. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Felix, Du meintest am 08.05.12: adding a bigger disk deleting/removing a smaller disk with simple commands. [...] Is it really possible to remove a disk from btrfs (created with -d single) without losing the data on that disk? When the system is configured with mkfs.btrfs -m raid1 -d raid0 then the above shown way is possible, it works (now) as expected. Ok - it needs some time. [...] What are the steps you're doing?! If this is really possible then there must be some sort of command that tells btrfs Hey, I wanne remove this disk from the fs, please copy all data to the other disks and then remove the disk. Is there such a command? Haven't heard of one, but that would be interesting. btrfs device add /dev/$newdisk ... (btrfs fi balance ...) btrfs device delete /dev/$olddisk ... (btrfs fi balance ...) I've told these simple steps many times in this mailing list. Since some kernel versions (at least since kernel 3.2.x) it seems to work without problems; btrfs-progs-packet from 2011-10-30. Otherwise if you remove a disk from a raid0 (doesn't matter if you have 2 or 5 or x disks in the fs, btrfs should stripe above all disks) your fs should be broken. Not with btrfs ... there it works even with mkfs.btrfs -m raid1 -d raid0 ... Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Hugo, Du meintest am 08.05.12: Otherwise if you remove a disk from a raid0 (doesn't matter if you have 2 or 5 or x disks in the fs, btrfs should stripe above all disks) your fs should be broken. Not with btrfs ... there it works even with mkfs.btrfs -m raid1 -d raid0 ... There is a big difference between orderly and planned removal of a hard disk, and disk goes away with no warning. And I know the difference ... When I first called for help I searched the failure in another place than in disk is dead. This is essentially the difference you've been talking about at cross- purposes all day. What I still hope (may be it's impossible): when 1 disk/partition fails, then the contents of the other disks is somehow restorable. And not irreproducable. Viele Gruesse! Helmut -- 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 3.3.4 damages filesystem (?)
Hallo,
never change a running system ...
For some months I run btrfs unter kernel 3.2.5 and 3.2.9, without
problems.
Yesterday I compiled kernel 3.3.4, and this morning I started the
machine with this kernel. There may be some ugly problems.
Copying something into the btrfs directory worked well for some files,
and then I got error messages (I've not copied them, something with IO
error under Samba).
Rebooting the machine with kernel 3.2.9 worked, copying 1 file worked,
but copying more than this file didn't work. And I can't delete this
file.
That doesn't please me - copying more than 4 TBytes wastes time and
money.
=== configuration =
/dev/sdc1 on /srv/MM type btrfs (rw,noatime)
/dev/sdc: SAMSUNG HD204UI: 25 °C
/dev/sdf: WDC WD30EZRX-00MMMB0: 30 °C
/dev/sdi: WDC WD30EZRX-00MMMB0: 29 °C
Data, RAID0: total=5.29TB, used=4.29TB
System, RAID1: total=8.00MB, used=352.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=149.00GB, used=5.00GB
Label: 'MMedia' uuid: 9adfdc84-0fbe-431b-bcb1-cabb6a915e91
Total devices 3 FS bytes used 4.29TB
devid3 size 2.73TB used 1.98TB path /dev/sdi1
devid2 size 2.73TB used 1.94TB path /dev/sdf1
devid1 size 1.82TB used 1.63TB path /dev/sdc1
Btrfs Btrfs v0.19
=== boot messages, kernel related ==
[boot with kernel 3.3.4]
May 7 06:55:26 Arktur kernel: ata5: exception Emask 0x10 SAct 0x0 SErr 0x1
action 0xe frozen
May 7 06:55:26 Arktur kernel: ata5: SError: { PHYRdyChg }
May 7 06:55:26 Arktur kernel: ata5: hard resetting link
May 7 06:55:31 Arktur kernel: ata5: COMRESET failed (errno=-19)
May 7 06:55:31 Arktur kernel: ata5: reset failed (errno=-19), retrying in 6
secs
May 7 06:55:36 Arktur kernel: ata5: hard resetting link
May 7 06:55:38 Arktur kernel: ata5: COMRESET failed (errno=-19)
May 7 06:55:38 Arktur kernel: ata5: reset failed (errno=-19), retrying in 9
secs
May 7 06:55:46 Arktur kernel: ata5: hard resetting link
May 7 06:55:47 Arktur kernel: ata5: COMRESET failed (errno=-19)
May 7 06:55:47 Arktur kernel: ata5: reset failed (errno=-19), retrying in 34
secs
May 7 06:56:21 Arktur kernel: ata5: hard resetting link
May 7 06:56:22 Arktur kernel: ata5: SATA link up 1.5 Gbps (SStatus 113
SControl 310)
May 7 06:56:22 Arktur kernel: ata5.00: configured for UDMA/100
May 7 06:56:22 Arktur kernel: ata5: EH complete
May 7 07:12:07 Arktur kernel: ata5.00: exception Emask 0x10 SAct 0x0 SErr
0x1 action 0xe frozen
May 7 07:12:07 Arktur kernel: ata5: SError: { PHYRdyChg }
May 7 07:12:07 Arktur kernel: ata5.00: failed command: WRITE DMA EXT
May 7 07:12:07 Arktur kernel: ata5.00: cmd 35/00:00:00:62:50/00:04:5e:00:00/e0
tag 0 dma 524288 out
May 7 07:12:07 Arktur kernel: res d8/d8:d8:d8:d8:d8/d8:d8:d8:d8:d8/d8
Emask 0x12 (ATA bus error)
May 7 07:12:07 Arktur kernel: ata5.00: status: { Busy }
May 7 07:12:07 Arktur kernel: ata5.00: error: { ICRC UNC IDNF }
May 7 07:12:07 Arktur kernel: ata5: hard resetting link
May 7 07:12:13 Arktur kernel: ata5: link is slow to respond, please be patient
(ready=-19)
May 7 07:12:15 Arktur kernel: ata5: SATA link up 1.5 Gbps (SStatus 113
SControl 310)
May 7 07:12:15 Arktur kernel: ata5.00: failed to IDENTIFY (I/O error,
err_mask=0x100)
May 7 07:12:15 Arktur kernel: ata5.00: revalidation failed (errno=-5)
May 7 07:12:20 Arktur kernel: ata5: hard resetting link
May 7 07:12:20 Arktur kernel: ata5: COMRESET failed (errno=-19)
May 7 07:12:20 Arktur kernel: ata5: reset failed (errno=-19), retrying in 10
secs
May 7 07:12:30 Arktur kernel: ata5: hard resetting link
May 7 07:12:30 Arktur kernel: ata5: COMRESET failed (errno=-19)
May 7 07:12:30 Arktur kernel: ata5: reset failed (errno=-19), retrying in 10
secs
May 7 07:12:40 Arktur kernel: ata5: hard resetting link
May 7 07:12:42 Arktur kernel: ata5: SATA link up 1.5 Gbps (SStatus 113
SControl 310)
May 7 07:12:43 Arktur kernel: ata5.00: configured for UDMA/100
May 7 07:12:43 Arktur kernel: ata5: EH complete
May 7 07:12:43 Arktur kernel: ata5.00: exception Emask 0x10 SAct 0x0 SErr
0x1 action 0xe frozen
May 7 07:12:43 Arktur kernel: ata5: SError: { PHYRdyChg }
May 7 07:12:43 Arktur kernel: ata5.00: failed command: WRITE DMA EXT
May 7 07:12:43 Arktur kernel: ata5.00: cmd 35/00:00:00:72:50/00:04:5e:00:00/e0
tag 0 dma 524288 out
May 7 07:12:43 Arktur kernel: res d0/d0:d0:d0:d0:d0/d0:d0:d0:d0:d0/d0
Emask 0x12 (ATA bus error)
May 7 07:12:43 Arktur kernel: ata5.00: status: { Busy }
May 7 07:12:43 Arktur kernel: ata5.00: error: { ICRC UNC IDNF }
May 7 07:12:43 Arktur kernel: ata5: hard resetting link
May 7 07:12:49 Arktur kernel: ata5: link is slow to respond, please be patient
(ready=-19)
May 7 07:12:50 Arktur kernel: ata5: SATA link up 1.5 Gbps (SStatus 113
SControl 310)
May 7 07:12:51 Arktur kernel: ata5.00: configured for UDMA/100
May 7 07:12:51 Arktur kernel: ata5: EH complete
May 7 07:12:51 Arktur
Re: kernel 3.3.4 damages filesystem (?)
Hallo, Hugo,
Du meintest am 07.05.12:
Yesterday I compiled kernel 3.3.4, and this morning I started the
machine with this kernel. There may be some ugly problems.
Copying something into the btrfs directory worked well for some
files, and then I got error messages (I've not copied them,
something with IO error under Samba).
[...]
Data, RAID0: total=5.29TB, used=4.29TB
System, RAID1: total=8.00MB, used=352.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=149.00GB, used=5.00GB
Label: 'MMedia' uuid: 9adfdc84-0fbe-431b-bcb1-cabb6a915e91
Total devices 3 FS bytes used 4.29TB
devid3 size 2.73TB used 1.98TB path /dev/sdi1
devid2 size 2.73TB used 1.94TB path /dev/sdf1
devid1 size 1.82TB used 1.63TB path /dev/sdc1
Btrfs Btrfs v0.19
=== boot messages, kernel related ==
[boot with kernel 3.3.4]
May 7 06:55:26 Arktur kernel: ata5: exception Emask 0x10 SAct 0x0
SErr 0x1 action 0xe frozen
May 7 06:55:26 Arktur kernel: ata5: SError: { PHYRdyChg }
May 7 06:55:26 Arktur kernel: ata5: hard resetting link
This is a hardware error. You have a device that's either dead or
dying. (Given the number of errors, probably already dead).
It seems to be undecided which status it has ...
Can I repair the system? Or have I to copy it to a set of other
disks?
If you have RAID-1 or RAID-10 on both data and netadata, then you
_should_ in theory just be able to remove the dead disk (physically),
then btrfs dev add a new one, btrfs dev del missing, and balance.
I haven't - I have a kind of copy/backup in the neighbourhood.
Viele Gruesse!
Helmut
--
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: kernel 3.3.4 damages filesystem (?)
Hallo, Fajar, Du meintest am 07.05.12: For some months I run btrfs unter kernel 3.2.5 and 3.2.9, without problems. Yesterday I compiled kernel 3.3.4, and this morning I started the machine with this kernel. There may be some ugly problems. Data, RAID0: total=5.29TB, used=4.29TB Raid0? Yaiks! Why not? You know the price of 1 3-TByte disk? The data isn't irreproducible, in this case. [...] May 7 07:15:19 Arktur kernel: sd 5:0:0:0: rejecting I/O to offline device May 7 07:15:19 Arktur kernel: end_request: I/O error, dev sdf, sector 0 May 7 07:15:19 Arktur kernel: sd 5:0:0:0: rejecting I/O to offline device May 7 07:15:19 Arktur kernel: lost page write due to I/O error on sdf1 That looks like a bad disk to me, and it shouldn't be related to the kernel version you use. But why does it happen just when I change the kernel? (Yes - I know: Murphy works reliable ...) Your best chance might be: - unmount the fs - get another disk to replace /dev/sdf, copy the content over with dd_rescue. Ata resets can be a PITA, so you might be better of by moving the failed disk to a usb external adapter, and du some creative combination of plug-unplug and selectively skip bad sectors manually (by passing -s to dd_rescue). Hmmm - I'll take a try ... - reboot, with the bad disk unplugged - (optional) run btrfs filesystem scrub (you might need to build btrfs-progs manually from git source). Last time I'd tried this command (some months ago) it had produced a completely unusable system of disks/partitions ... or simply read the entire fs (e.g. using tar to /dev/null, or whatever). It should check the checksum of all files and print out which files are damaged (either in stdout or syslog). And that's the other try - I had to use it for another disk (also WD, but only 2 TByte - I could watch how it died ...). Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Hugo,
Du meintest am 07.05.12:
=== boot messages, kernel related ==
[boot with kernel 3.3.4]
May 7 06:55:26 Arktur kernel: ata5: exception Emask 0x10 SAct 0x0
SErr 0x1 action 0xe frozen
May 7 06:55:26 Arktur kernel: ata5: SError: { PHYRdyChg }
May 7 06:55:26 Arktur kernel: ata5: hard resetting link
[...]
This is a hardware error. You have a device that's either dead or
dying. (Given the number of errors, probably already dead).
It's dead - R.I.P.
I've tried it with a SATA-USB-adapter - that adapter produces dmesg
lines when connecting or disconnecting.
And this special drive doesn't tell anything now. Shit.
Viele Gruesse!
Helmut
--
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: kernel 3.3.4 damages filesystem (?)
Hallo, Hugo, Du meintest am 07.05.12: It's dead - R.I.P. Sorry to be the bearer of bad news. I don't think we can point the finger at btrfs here. a) you know what to do with the bearer? b) I like such errors - completely independent, but simultaneously. It looks like you've lost most of your data -- losing a RAID-0 stripe across the whole FS isn't likely to have left much of it intact. I'm just going back to ext4 - then one broken disk doesn't disturb the contents of the other disks. The data is not very valuable - DVB video mpegs. Most of the files are repeated on and on. If you've got the space (or the money to get it), mkfs.btrfs -m raid1 -d raid1 would have saved you here. About 400 ... 500 Euro for backing up videos? Not necessary. (No: I don't count the minutes and hours working with the system ...) [ Incidentally, thinking about it, the failure coming at a kernel upgrade could well be down to the additional stress of the power-down/reboot finally pushing a bad drive over the edge. ] Just now it's again an open system; I had to wobble the cables too ... Maybe the SATA-PCI-controller needs to be replaced too ... Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Felix, Du meintest am 07.05.12: I'm just going back to ext4 - then one broken disk doesn't disturb the contents of the other disks. ?! If you use raid0 one broken disk will always disturb the contents of the other disks, that is what raid0 does, no matter what filesystem you use. Yes - I know. But btrfs promises that I can add bigger disks and delete smaller disks on the fly. For something like a video collection which will grow on and on an interesting feature. And such a (big) collection does need a gradfather-father-son backup, that's no critical data. With a file system like ext2/3/4 I can work with several directories which are mounted together, but (as said before) one broken disk doesn't disturb the others. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Hugo, Du meintest am 07.05.12: With a file system like ext2/3/4 I can work with several directories which are mounted together, but (as said before) one broken disk doesn't disturb the others. mkfs.btrfs -m raid1 -d single should give you that. What's the difference to mkfs.btrfs -m raid1 -d raid0 (what I have used the last time)? Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Daniel, Du meintest am 07.05.12: Yes - I know. But btrfs promises that I can add bigger disks and delete smaller disks on the fly. For something like a video collection which will grow on and on an interesting feature. And such a (big) collection does need a gradfather-father-son backup, that's no critical data. With a file system like ext2/3/4 I can work with several directories which are mounted together, but (as said before) one broken disk doesn't disturb the others. How can you do that with ext2/3/4? If you mean create several different filesystems and mount them separately then that's very different from your current situation. What you did in this case is comparable to creating a raid0 array out of your disks. I don't see how an ext filesystem is going to work any better if one of the disks drops out than with a btrfs filesystem. mkfs.btrfs -m raid1 -d raid0 with 3 disks gives me a cluster which looks like 1 disk/partition/ directory. If one disk fails nothing is usable. (Yes - I've read Hugo's explanation of -d single, I'll try this way) With ext2/3/4 I mount 2 disks/partitions into the first disk. If one disk fails the contents of the 2 other disks is still readable, It sounds like what you're thinking of is creating several separate ext filesystems and then just mounting them separately. Yes - that's the old way. It's reliable but ugly. There's nothing inherently special about doing this with ext, you can do the same thing with btrfs and it would amount to about the same level of protection (potentially more if you consider [meta]data checksums important but potentially less if you feel that ext is more robust for whatever reason). No - as just mentionend: there's a big difference when one disk fails. If you want to survive losing a single disk without the (absolute) fear of the whole filesystem breaking you have to have some sort of redundancy either by separating filesystems or using some version of raid other than raid0. No - since some years I use a kind of outsourced backup. A copy of all data is on a bundle of disks somewhere in the neighbourhood. As mentionend: the data isn't business critical, it's just nice to have. It's not worth something like raid1 or so (with twice the costs of a non raid solution). I suppose the volume management of btrfs is sort of confusing at the moment but when btrfs promises you can remove disks on the fly it doesn't mean you can just unplug disks from a raid0 without telling btrfs to put that data elsewhere first. No - it's not confusing. It only needs a kind of recipe and much time: btrfs device add ... btrfs filesystem balance ... (perhaps no necessary) btrfs device delete ... btrfs filesystem balance ... (perhaps not necessary) No intellectual challenge. And completely different to hot pluggable. Viele Gruesse! Helmut -- 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: kernel 3.3.4 damages filesystem (?)
Hallo, Daniel, Du meintest am 07.05.12: mkfs.btrfs -m raid1 -d raid0 with 3 disks gives me a cluster which looks like 1 disk/partition/ directory. If one disk fails nothing is usable. How is that different from putting ext on top of a raid0? Classic raid0 doesn't allow deleting/removing disks from a cluster. With ext2/3/4 I mount 2 disks/partitions into the first disk. If one disk fails the contents of the 2 other disks is still readable, There is nothing that prevents you from using this strategy with btrfs. How? I've tried many installations of btrfs, sometimes 1 disk failed, and then the data on all other disks was inaccessible. Viele Gruesse! Helmut -- 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: Interpreting Output of btrfs fi show
Hallo, Bart, Du meintest am 26.04.12: As for the two filesystems shown in btrfs fi show... I have no clue what that is about. Did you maybe make a mistake to create a btrfs filesystem on the whole disk at first? That is possible. But afterwards I certainly repartioned the device and created a btrfs filesystem on /dev/sda1. Maybe this info is only in the partition table? I understand that I should avoid mounting /dev/sda in this situation. Well I think there is a btrfs superblock still present from the full-disk filesystem. Due to the offset of the first partition from the start of the disk, this superblock was not overwritten when you created the filesystem inside the partition. Sounds familiar ... I now use to delete about the first 10 MByte of the target disk via dd if=/dev/zero Viele Gruesse! Helmut -- 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: Interpreting Output of btrfs fi show
Hallo, David, Du meintest am 26.04.12: I now use to delete about the first 10 MByte of the target disk via dd if=/dev/zero FYI, the minimal amount of data you need to rewrite is 4k: dd if=/dev/zero of=/dev/ice bs=1k count=4 seek=64 Thank you - I'll try to remember the next time I need this command! Viele Gruesse! Helmut -- 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: looking for non existent devices
Hallo, Ilya, Du meintest am 21.03.12: When I run btrfs filesystem label or btrfs scrub status /dev/sdxn then I get a lot of error messages with (p.e.) failed to read /dev/hda6: No such device or address failed to read /dev/sdm7: No such device or address failed to read /dev/sr3: No such device or address I think this has been fixed in recent btrfs-progs, commit 32eff711. It is fixed in some (or many) places, it is not fixed everywhere. I had used kernel 3.2.9 Viele Gruesse! Helmut -- 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: looking for non existent devices
Hallo, Ilya, Du meintest am 21.03.12: I think this has been fixed in recent btrfs-progs, commit 32eff711. It is fixed in some (or many) places, it is not fixed everywhere. I had used kernel 3.2.9 32eff711 is supposed to fix it in more places, filesystem label and scrub status included. This is purely a userspace issue, commit and repo I pointed you to are for btrfs-progs, not the kernel. You are probably on branch master, it doesn't have that commit yet, only dangerdonteveruse branch does. Ok - I'll take a try. But it's not urgent ... Viele Gruesse! Helmut -- 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: fix btrfs_ioctl_dev_info() crash on missing device
Hallo, Stefan, Du meintest am 19.03.12: When a filesystem is mounted with the degraded option, it is possible that some of the devices are not there. btrfs_ioctl_dev_info() crashs in this case because the device name is a NULL pointer. This ioctl was only used for scrub. Just for curiosity: can that happen when I first delete a partition/disk and then run btrfs scrub start? Viele Gruesse! Helmut -- 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: scrub stops the machine
Hallo, Martin, Du meintest am 17.03.12: btrfs scrub start /mnt/btr and all was dead. Really dead. No access via keybord, no access via SSH. what kernel are you using? As mentioned some hours ago: 3.2.9 (self made). Are you by any chance on a 32 bit maschine? Yes. Second try with kernel 3.2.5: same problem. The system is completely dead. Viele Gruesse! Helmut -- 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
looking for non existent devices
Hallo, linux-btrfs, some commands still look for non existent devices. I don't use udev. When I run btrfs filesystem show only the existent devices are shown - fine. When I run btrfs filesystem label or btrfs scrub status /dev/sdxn then I get a lot of error messages with (p.e.) failed to read /dev/hda6: No such device or address failed to read /dev/sdm7: No such device or address failed to read /dev/sr3: No such device or address Kernel 3.2.9 Viele Gruesse! Helmut -- 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
not enough space with data raid0
Hallo, linux-btrfs, I've (once more) created my test system: mkfs.btrfs -d raid0 -m raid1 /dev/sdb1 /dev/sdc1 73 GB + 146 GB. Then I mounted it and copied about 150 GByte onto it. But copying was incomplete, the job ended with no space on ... # btrfs fi show Label: 'Scsi' uuid: e30586e9-a903-4d17-8ec0-1781457212c6 Total devices 2 FS bytes used 134.86GB devid1 size 68.37GB used 68.37GB path /dev/sdb1 devid2 size 136.73GB used 68.35GB path /dev/sdc1 Btrfs Btrfs v0.19 # btrfs fi df mountpoint Data, RAID0: total=134.68GB, used=134.67GB Data: total=8.00MB, used=8.00MB System, RAID1: total=8.00MB, used=16.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=1.00GB, used=185.39MB Metadata: total=8.00MB, used=0.00 # df mountpoint Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc1 215059324 141597364 8724 100% /mnt/btr # fdisk -l Disk /dev/sdb: 73.4 GB, 73407868928 bytes Disk /dev/sdc: 146.8 GB, 146814976000 bytes --- Where is the problem, how can I use the full space? Viele Gruesse! Helmut -- 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: not enough space with data raid0
Hallo, Chris, Du meintest am 17.03.12: Where is the problem, how can I use the full space? Which kernel was this with Helmut? Kernel 3.2.9 (self made) btrfs-progs-20111030 Viele Gruesse! Helmut -- 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: not enough space with data raid0
Hallo, Hugo, Du meintest am 17.03.12: [no space left on device ...] Where is the problem, how can I use the full space? Effectively it's missing the trigger to rebalance when the 'primary' device starts to get full, or just to randomly spread the data between the devices. No, a balance isn't going to help here. RAID-0 requires a minimum of 2 chunks in a block group. With two disks, you're only going to be able to fill the smallest one before you run out of space. Ok - it happens only with 2 disks/Partitions? I've continued playing; added a 3rd partition/device and then balanced: # btrfs device add /dev/sdd1 /mnt/btr ## 73 + 146 + 146 GByte # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc1 358432300 225400136 59842800 80% /mnt/btr # added about 70 GByte (all together more than 3 times the smallest partition) # btrfs fi show Label: 'Scsi' uuid: e30586e9-a903-4d17-8ec0-1781457212c6 Total devices 3 FS bytes used 214.67GB devid1 size 68.37GB used 68.37GB path /dev/sdb1 devid3 size 136.73GB used 41.01GB path /dev/sdd1 devid2 size 136.73GB used 109.36GB path /dev/sdc1 Btrfs Btrfs v0.19 # btrfs fi df /mnt/btr Data, RAID0: total=216.71GB, used=214.38GB System, RAID1: total=8.00MB, used=24.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=1.00GB, used=295.13MB = # btrfs fi balance /mnt/btr # btrfs fi show Label: 'Scsi' uuid: e30586e9-a903-4d17-8ec0-1781457212c6 Total devices 3 FS bytes used 214.67GB devid1 size 68.37GB used 67.34GB path /dev/sdb1 devid3 size 136.73GB used 40.85GB path /dev/sdd1 devid2 size 136.73GB used 107.85GB path /dev/sdc1 Btrfs Btrfs v0.19 # btrfs fi df /mnt/btr Data, RAID0: total=215.01GB, used=214.38GB System, RAID1: total=8.00MB, used=24.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=512.00MB, used=294.88MB -- Looks as desired, the 3-disks-system contains more than 3 times the smallest disk. Balancing hasn't redistributed the contents - no problem. By the way: you should name the prefixes in the NIST way for powers of 2: KiB, MiB, GiB. Or change to decimal prefixes. Viele Gruesse! Helmut -- 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: not enough space with data raid0
Hallo, Hugo, Du meintest am 17.03.12: What's the 'solution' though to Hugo's situation? By 'solution' I mean the highest-utility way of dealing with unequal devices problem in a two or more -up setting. Use mkfs.btrfs -d single, as I said in another part of this thread. Does single allow adding new (bigger) disks and removing old (smaller) disks? Viele Gruesse! Helmut -- 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
scrub stops the machine
Hallo, linux-btrfs, next problem ... I had tested the next possible steps after deleting a partition. btrfs device delete /dev/sdb1 /mnt/btr worked well. Then btrfs scrub start /mnt/btr and all was dead. Really dead. No access via keybord, no access via SSH. Restarted the machine, mounted the btrfs bundle, then again btrfs scrub start /mnt/btr and the same reaction. Dead. No entry in /var/log/messages, no entry in /var/log/warn. Viele Gruesse! Helmut -- 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: scrub stops the machine
Hallo, Arne, Du meintest am 17.03.12 zum Thema Re: scrub stops the machine: On 03/17/12 17:35, Helmut Hullen wrote: btrfs scrub start /mnt/btr and all was dead. Really dead. No access via keybord, no access via SSH. what kernel are you using? As mentioned some hours ago: 3.2.9 (self made). Are you by any chance on a 32 bit maschine? Yes. Viele Gruesse! Helmut -- 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: scrub stops the machine
Hallo, Martin, Du meintest am 17.03.12: btrfs scrub start /mnt/btr and all was dead. Really dead. No access via keybord, no access via SSH. Kernel 3.2.9 [...] Please review the thread I started with subject: 3.2-rc4: scrubbing locks up the kernel, then hung tasks on boot Your system has run for some seconds and has sent messages. My syste seems to die immediately after receiving scrub start. Viele Gruesse! Helmut -- 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-convert options
Hallo, Hugo, Du meintest am 27.02.12: I want to change some TByte disks (at least one) from ext4 to btrfs. And I want -d raid0 -m raid1. Is it possible to tell btrfs-convert especially these options for data and metadata? Or have I to use mkfs.btrfs (and then copy the backup) when I want these options? The other alternative is to get hold of 3.3-rcX and the latest userspace tools (currently in the dangerdonteveruse branch, but should be in master very soon), and use the restriper after you've converted. H - I don't yet dare these experiments with really big disks ... Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, Hugo, Du meintest am 27.02.12: mkfs.btrfs creates a new filesystem. The -L option sets the label for the newly-created FS. It *cannot* be used to change the label of an existing FS. The safest way may be deleting this option ... it seems to work as expected only when I create a new FS on 1 disk/partition. I've said this several times: Your expectations are wrong. You don't label partitions. Yes - now I know. But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with mkfs.btrfs). Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, David, Du meintest am 27.02.12: [deleting btrfs partition] OK, the real problem you're seeing is that when btrfs removes a device from the filesystem, that device is not modified in any way. This means that the old superblock is left behind on it, containing the FS label information. What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and /dev/zero. A correction here: if the device being removed is writable, the superblock is cleared so it's not recognized as a part of any other fs: [...] Doing this manually means zeroing 4k block at all offsets up to partition size: Superblock 0 offset 65536 Superblock 1 offset 67108864 Superblock 2 offset 274877906944 Superblock 3 offset 1125899906842624 Superblock 4 offset 4611686018427387904 My actual experiments: dd if=/dev/zero of=/dev/sdxn bs=16M count=1 seems to be enough. Perhaps deleting the first 16 MByte is too much. Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, Duncan, Du meintest am 27.02.12: I've said this several times: Your expectations are wrong. You don't label partitions. Yes - now I know. But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with mkfs.btrfs). AFAIK, it works in the same way... that is, it labels the, in that case, ext2/3/4 filesystem, in this case (mkfs.btrfs), btrfs filesystem. From the manpages: mkfs.btrfs (aka mkbtrfs): -L, --label name Specify a label for the filesystem. mkfs.ext2/3/4 (aka mke2fs): -L new-volume-label Set the volume label for the filesystem to new-volume-label. The maximum length of the volume label is 16 bytes. But there's a small difference: mke2fs -L MyLabel /dev/sdn4 only sets/changes the label (ok - it tests the type of the partition and refuses labeling if the type doesn't fit). mkfs.btrfs -L MyLabel /dev/sdn4 not only sets/changes the label but also (re-)creates a btrfs filesystem, using the default parameters. I had to learn this difference ... Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, Hugo, Du meintest am 27.02.12: But there's a small difference: mke2fs -L MyLabel /dev/sdn4 only sets/changes the label (ok - it tests the type of the partition and refuses labeling if the type doesn't fit). OK, I have just tried this out. It does set the filesystem label. It also wipes the filesystem, as I expected it to. You clearly aren't doing this on existing filesystems with data in them. I should have tested it ... sorry. I've always labeled my ext[234] partitions with e2label. And because I hadn't found such a simple command for btrfs I took mkfs.btrfs -L instead of btrfs fi label mountpoint. Viele Gruesse! Helmut -- 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: filesystem full when it's not? out of inodes? huh?
Hallo, Duncan, Du meintest am 26.02.12: It's astonishing to me the number of people that come in here complaining about problems with a filesystem the kernel option of which says Title: Btrfs filesystem (EXPERIMENTAL) Unstable disk format Description (excerpt): Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non-critical data. Just take a look at Fedora. The maintainers had planned to use btrfs as standard filesystem for Fedora 16 (but haven't done so), they had planned to use btrfs for Fedora 17, but perhaps hesitate, see https://fedorahosted.org/fesco/ticket/704 There are some other distributions which also seem to (perhaps) follow the bleading edge. And therefore end users believe that using btrfs is safe. (I've learned my lesson ...) Just for the record: using btrfs (when it runs stable) may reduce many other problems on my system. I'm still hoping. Viele Gruesse! Helmut -- 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
LABEL only 1 device
Hallo, linux-btrfs, maybe it's a big error using the commmand mkfs.btrfs -L xyz /dev/sdx1 /dev/sdy1 /dev/sdz1 (and so labelling many partitions) because each device/partition gets the same label. Mounting seems to be no problem, but (p.e.) delete doesn't kill the btrfs informations shown with (p.e.) blkid /dev/sdy1, especially it doesn't delete the label. Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, Hugo, Du meintest am 26.02.12: Mounting seems to be no problem, but (p.e.) delete doesn't kill the btrfs informations shown with (p.e.) blkid /dev/sdy1, especially it doesn't delete the label. What do you mean by delete here? btrfs device delete device path The label is a *filesystem* label, not a label for the block device(s) it lives on, so it doesn't make much sense to talk about putting an FS label on only one of the devices that the FS is on. My (planned) usual work (once a year or so): btrfs device add biggerdevice path btrfs filesystem balance path btrfs device delete smallerdevice path And the devices are (p.e.) /dev/sdj1, /dev/sdk1 etc. (partitions on a device). Therefor I can see some informations via (p.e.) blkid /dev/sdj1 I prefer LABELling the devices/partitions, and then I'd seen that the option -L makes problems when I use it for more than 1 device/ partition. With other file systems there's no real problem with the same label for several partitions - it doesn't work. But btrfs bundles these partitions (perhaps sometimes/most times regardless of the labels of the other partitions). Viele Gruesse! Helmut -- 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
device delete kills contents
Hallo, linux-btrfs, I've (once again) tried add and delete. First, with 3 devices (partitions): mkfs.btrfs -d raid0 -m raid1 /dev/sdk1 /dev/sdl1 /dev/sdm1 Mounted (to /mnt/btr), filled with about 100 GByte data. Then btrfs device add /dev/sdj1 /mnt/btr results in # show Label: none uuid: 6bd7d4df-e133-47d1-9b19-3c7565428770 Total devices 4 FS bytes used 100.44GB devid3 size 68.37GB used 44.95GB path /dev/sdm1 devid2 size 136.73GB used 43.95GB path /dev/sdl1 devid1 size 16.96GB used 16.96GB path /dev/sdk1 devid4 size 136.73GB used 0.00 path /dev/sdj1 Btrfs Btrfs v0.19 # df Data, RAID0: total=103.81GB, used=100.30GB Data: total=8.00MB, used=0.00 System, RAID1: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=1.00GB, used=136.29MB Metadata: total=8.00MB, used=0.00 - # Then mkfs filesystem balance /mnt/btr # show Label: none uuid: 6bd7d4df-e133-47d1-9b19-3c7565428770 Total devices 4 FS bytes used 100.44GB devid3 size 68.37GB used 42.94GB path /dev/sdm1 devid2 size 136.73GB used 43.20GB path /dev/sdl1 devid1 size 16.96GB used 16.94GB path /dev/sdk1 devid4 size 136.73GB used 2.20GB path /dev/sdj1 Btrfs Btrfs v0.19 # df Data, RAID0: total=104.75GB, used=100.30GB System, RAID1: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=256.00MB, used=136.23MB - # Next step: btrfs device delete /dev/sdk1 /mnt/btr # show Label: none uuid: 6bd7d4df-e133-47d1-9b19-3c7565428770 Total devices 4 FS bytes used 100.43GB devid3 size 68.37GB used 43.00GB path /dev/sdm1 devid2 size 136.73GB used 43.26GB path /dev/sdl1 devid4 size 136.73GB used 17.26GB path /dev/sdj1 *** Some devices missing Btrfs Btrfs v0.19 # df Data, RAID0: total=103.00GB, used=100.30GB System, RAID1: total=8.00MB, used=12.00KB Metadata, RAID1: total=256.00MB, used=131.62MB - All commands seemed to work well, without any error message. blkid showed the expected data, especially blkid /dev/sdk1 shows nothing - the partitions seems to be really empty. Unmounted, mounted again: # show Btrfs Btrfs v0.19 # df Data: total=8.00MB, used=64.00KB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=24.00KB Metadata: total=8.00MB, used=0.00 show doesn't show any part of the bundle of 3 partitions. That's more than I've expected from the option delete ... - Famous last words from dmesg: device fsid 6bd7d4df-e133-47d1-9b19-3c7565428770 devid 3 transid 437 /dev/sdm1 device fsid 6bd7d4df-e133-47d1-9b19-3c7565428770 devid 2 transid 437 /dev/sdl1 device fsid 6bd7d4df-e133-47d1-9b19-3c7565428770 devid 4 transid 437 /dev/sdj1 device label SCSI devid 1 transid 7 /dev/sdj1 btrfs: disk space caching is enabled device label SCSI devid 1 transid 10 /dev/sdj1 btrfs: disk space caching is enabled device label SCSI devid 1 transid 13 /dev/sdj1 btrfs: disk space caching is enabled device fsid 6bd7d4df-e133-47d1-9b19-3c7565428770 devid 3 transid 437 /dev/sdm1 btrfs: disk space caching is enabled btrfs: failed to read chunk tree on sdm1 btrfs: open_ctree failed device fsid 6bd7d4df-e133-47d1-9b19-3c7565428770 devid 2 transid 437 /dev/sdl1 btrfs: disk space caching is enabled btrfs: failed to read chunk tree on sdm1 btrfs: open_ctree failed device label SCSI devid 1 transid 16 /dev/sdj1 btrfs: disk space caching is enabled end_request: I/O error, dev fd0, sector 0 end_request: I/O error, dev fd0, sector 0 -- My dmesg doesn't write time stamps, there may be some lines from previous tests. --- Kernel 3.2.5 (self made), btrfs from darksatanic.net, bztfs-progs- unstable. Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, Hugo, Du meintest am 26.02.12: My (planned) usual work (once a year or so): btrfs device add biggerdevice path btrfs filesystem balance path btrfs device delete smallerdevice path OK, the real problem you're seeing is that when btrfs removes a device from the filesystem, that device is not modified in any way. This means that the old superblock is left behind on it, containing the FS label information. What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and /dev/zero. Ok - I'll try again (not today ...). If I remember correct in early times deleting only the first block of the partition didn't reach ... My last try with delete let me believe that btrfs had deleted the critical informations; I had tested it with blkid. But looking into the first sector of the partition may be more reliable. I prefer LABELling the devices/partitions, and then I'd seen that the option -L makes problems when I use it for more than 1 device/ partition. [...] I say again, partitions are not labelled. *Filesystems* are labelled. I think that with a GPT you can refer to the disk itself and its partitions by a UUID each, but I'm not 100% certain. My last try: mkfs.btrfs -d raid0 -m raid1 /dev/sdk1 /dev/sdl1 /dev/sdm1 mkfs.btrfs -L SCSI /dev/sdk1 seemed to work. mount LABEL=SCSI /mnt/btr worked as expected, the bundle of 3 partitions was mounted. And only / dev/sdk1 got this label, no other partition. Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, Hugo, Du meintest am 26.02.12: What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and /dev/zero. Ok - I'll try again (not today ...). If I remember correct in early times deleting only the first block of the partition didn't reach ... No, it won't -- the first superblock on btrfs is at 64k into the device. Most filesystems do something similar, because there's other things that occasionally put metadata in the first part of the device, so it avoids having the FS's superblock overwritten accidentally. Ok - but deleting the first 100 kByte or the first 1 MByte does reach? Last times I'd run a job which deleted all (but that's nasty for disks with much more than 100 GByte ...) mkfs.btrfs -L SCSI /dev/sdk1 seemed to work. mount LABEL=SCSI /mnt/btr worked as expected, the bundle of 3 partitions was mounted. And only / dev/sdk1 got this label, no other partition. That's because you've just destroyed part of the original filesystem that was on /dev/sd[klm]1 and created a new single-device filesystem on /dev/sdk1. mkfs.btrfs creates a new filesystem. The -L option sets the label for the newly-created FS. It *cannot* be used to change the label of an existing FS. If you want to do that, use btrfs filesystem label. H - I'll try ... Thank you! - Label: 'SCSI' uuid: 8e287956-d73f-46cb-8938-b00315c596c6 Total devices 1 FS bytes used 92.00KB devid1 size 136.73GB used 2.04GB path /dev/sdj1 Label: 'Scsi' uuid: b59caf71-1a38-47cc-bad3-c2d87357c971 Total devices 3 FS bytes used 9.09GB devid2 size 136.73GB used 4.01GB path /dev/sdl1 devid3 size 68.37GB used 5.01GB path /dev/sdm1 devid1 size 16.96GB used 5.02GB path /dev/sdk1 Btrfs Btrfs v0.19 looks good ... Viele Gruesse! Helmut -- 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: LABEL only 1 device
Hallo, Hugo, Du meintest am 26.02.12: mkfs.btrfs creates a new filesystem. The -L option sets the label for the newly-created FS. It *cannot* be used to change the label of an existing FS. The safest way may be deleting this option ... it seems to work as expected only when I create a new FS on 1 disk/partition. If you want to do that, use btrfs filesystem label. And that seems to work as I expected - fine. Adding a device works, deleting a device works. Fine! Now I'll try the job with my Terabyte disks. (Yes - I have backups ...) Viele Gruesse! Helmut -- 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-convert options
Hallo, linux-btrfs, I want to change some TByte disks (at least one) from ext4 to btrfs. And I want -d raid0 -m raid1. Is it possible to tell btrfs-convert especially these options for data and metadata? Or have I to use mkfs.btrfs (and then copy the backup) when I want these options? Viele Gruesse! Helmut -- 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] Btrfs: fix inaccurate available space on raid0 profile
Hallo, Miao, Du meintest am 14.12.11: When we use raid0 as the data profile, df command may show us a very inaccurate value of the available space, which may be much less than the real one. It may make the users puzzled. Fix it by changing the calculation of the available space, and making it be more similar to a fake chunk allocation. Sounds very good! Viele Gruesse! Helmut -- 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: What is best practice when partitioning a device that holds one or more btr-filesystems
Hallo, Wilfred, Du meintest am 14.12.11: What is best practice when partitioning a device that holds one or more btr-filesystems That depends ... My favourite installation is a bundle of 2-TByte-disks which btrfs presents as one big disk. data=raid0, metadata=raid1 It's a kind of archive, p.e. for video *.mpeg Viele Gruesse! Helmut -- 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: Resize command syntax wrong?
Hallo, Phillip, Du meintest am 01.12.11: balance != resize [...] That has nothing to do with resize. Right, so why are you talking about balance when this thread is about resize? Ooops - sorry! Viele Gruesse! Helmut -- 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: Resize command syntax wrong?
Hallo, Phillip, Du meintest am 30.11.11: Currently the resize command is under filesystem, and takes a path to the mounted filesystem. This seems wrong to me. Shouldn't it be under device, and take a path to a device to resize? No - it's a filesystem operation. p.e. You start with a system of 2 disks. They get filled nearly simultaneously. Then you add a 3rd disk (which is empty at that time). Now it's a good idea to run balance for equalizing the filling. Viele Gruesse! Helmut -- 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: Resize command syntax wrong?
Hallo, Roman, Du meintest am 01.12.11: What if I need to replace an individual device with a smaller or a larger one? 1) add the new device 2) balance (may be it's not necessary) 3) run remove for the individual device 4) remove it 5) balance Viele Gruesse! Helmut -- 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: Resize command syntax wrong?
Hallo, Phillip, Du meintest am 30.11.11: You start with a system of 2 disks. They get filled nearly simultaneously. Then you add a 3rd disk (which is empty at that time). Now it's a good idea to run balance for equalizing the filling. balance != resize I know. p.e. Start with 1 disk with 2 GB and 1 disk with 4 GByte Fill it with 2 Gbyte data, each disk gets 1 GByte. Add a disk with 10 GByte, run balance: each disk gets about 700 MByte. That has nothing to do with resize. Viele Gruesse! Helmut -- 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: fsck with err is 1
Hallo, Blair, Du meintest am 23.11.11: I can't answer that, but I can tell you that fsck for btrfs right now is almost useless. It can't fix anyting. Thank you, I've read that fsck doesn't fix anything. I was curious if doing the scrub would resolve it. I had tried ... about 4 Tbyte data have gone. 3 disks bundled with data=raid0, metadata=raid1. One disk had problems, before I run scrub I could read most files, Running scrub: all had gone. One big problem of btrfs seems to be: you can't see on which partition/ disk the defect sector (or something else) may be, if there is 1 error in 1 partition you have to restore the complete bundle of disks/ partitions. Yes - I know: btrfs is still under construction. In my special case: the 4 TByte are a kind of video archive. No valuable data, only nice to have. And old people still know the behaviour of old 35 mm film and/or VHS cassettes: they have errors. But these errors don't damage the whole archive. Viele Gruesse! Helmut -- 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: fsck with err is 1
Hallo, Jan, Du meintest am 23.11.11: One big problem of btrfs seems to be: you can't see on which partition/ disk the defect sector (or something else) may be A recent kernel (3.2, still rc) will tell you the byte number when an error occurs, and also give the the opportunity to resolve this address to all files affected. May be. I had used the brand new kernel 3.1. btrfs may be fine when it works as proposed. It's still under heavy construction. I had to rebuild my 4-TByte archive the second time within 1 year - that's no reliable system. May be the situation for really big bundles of disk gets better when something like raid 5 does work. I'll wait. Viele Gruesse! Helmut -- 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-progs: mention libattr dependency in INSTALL file
Hallo, Ilya, Du meintest am 02.11.11: The Btrfs utility programs require libuuid to build. This can be found in the e2fsprogs sources, and is usually available as libuuid or e2fsprogs-devel from various distros. The other dependency is libattr +(libattr1-dev in Debian-based distros). Just for information: my btrfs-progs packet (integration-20111030) shows (via ldd) libcom_err.so.2 = /lib/libcom_err.so.2 (0x401cc000) libcom_err.so.3 = /usr/X11R6/lib/libcom_err.so.3 (0x40061000) libc.so.6 = /lib/libc.so.6 (0x4003b000) libext2fs.so.2 = /lib/libext2fs.so.2 (0x40037000) libkrb5support.so.0 = /usr/lib/libkrb5support.so.0 (0x401cf000) /lib/ld-linux.so.2 (0x4000) libpthread.so.0 = /lib/libpthread.so.0 (0x40037000) libresolv.so.2 = /lib/libresolv.so.2 (0x401d2000) libuuid.so.1 = /lib/libuuid.so.1 (0x40037000) No libattr. No special compiler option. Slackware 13.37 Viele Gruesse! Helmut -- 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
what does scrub mean?
Hallo, I'd like to get some explanations ... # btrfs filesystem show Label: 'MMedia' uuid: 120b036a-883f-46aa-bd9a-cb6a1897c8d2 Total devices 3 FS bytes used 3.80TB devid1 size 1.82TB used 1.29TB path /dev/sdg1 devid3 size 1.81TB used 1.29TB path /dev/sdc1 devid2 size 1.81TB used 1.28TB path /dev/sdb1 Btrfs Btrfs v0.19 # btrfs filesystem df /srv/MM Data, RAID0: total=3.83TB, used=3.80TB System, RAID1: total=16.00MB, used=248.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=16.25GB, used=4.93GB # btrfs scrub status /srv/MM scrub status for 120b036a-883f-46aa-bd9a-cb6a1897c8d2 scrub resumed at Wed Nov 2 17:02:07 2011 and was aborted after 16519 seconds total bytes scrubbed: 1.79TB with 61 errors error details: read=4 verify=21 csum=36 corrected errors: 28, uncorrectable errors: 24, unverified errors: 0 # Why has scrub finished its work after less than 1/3 of the bundle? Viele Gruesse! Helmut -- 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: what does scrub mean?
Hallo, Arne, Du meintest am 02.11.11: # btrfs scrub status /srv/MM scrub status for 120b036a-883f-46aa-bd9a-cb6a1897c8d2 scrub resumed at Wed Nov 2 17:02:07 2011 and was aborted after 16519 secondstotal bytes scrubbed: 1.79TB with 61 errors error details: read=4 verify=21 csum=36 corrected errors: 28, uncorrectable errors: 24, unverified errors: 0 can you also show the output in dmesg? Maybe the extent tree is damaged to a point where it can't be fully traversed. from /var/log/warn: Nov 1 18:04:31 Arktur kernel: parent transid verify failed on 8520218480640 wanted 57343 found 55967 Nov 1 18:08:14 Arktur kernel: parent transid verify failed on 5340294963200 wanted 57354 found 42286 ( btrfs scrub start /srv/MM ) Nov 1 19:58:46 Arktur kernel: parent transid verify failed on 21094400 wanted 57401 found 47987 Nov 1 19:58:46 Arktur kernel: btrfs: failed to read chunk tree on sdg1 Nov 1 19:58:46 Arktur kernel: btrfs: open_ctree failed Nov 1 19:58:50 Arktur kernel: parent transid verify failed on 21094400 wanted 57401 found 47987 Nov 1 19:58:50 Arktur kernel: btrfs: failed to read chunk tree on sdg1 Nov 1 19:58:50 Arktur kernel: btrfs: open_ctree failed Nov 1 20:12:30 Arktur kernel: parent transid verify failed on 21094400 wanted 57401 found 47987 Nov 1 20:12:30 Arktur kernel: btrfs: failed to read chunk tree on sdg1 Nov 1 20:12:30 Arktur kernel: btrfs: open_ctree failed Nov 1 20:12:50 Arktur kernel: parent transid verify failed on 21094400 wanted 57401 found 47987 Nov 1 20:12:50 Arktur kernel: btrfs: failed to read chunk tree on sdg1 Nov 1 20:12:50 Arktur kernel: btrfs: open_ctree failed Nov 1 21:54:40 Arktur kernel: btrfs: fixed up at 21094400 Nov 1 21:54:42 Arktur kernel: parent transid verify failed on 8520776052736 wanted 57347 found 55978 Nov 1 21:55:02 Arktur kernel: parent transid verify failed on 8520777674752 wanted 57362 found 57240 Nov 1 21:58:20 Arktur kernel: btrfs: fixed up at 21094400 Nov 1 21:58:20 Arktur kernel: parent transid verify failed on 8520776052736 wanted 57347 found 55978 Nov 1 21:58:26 Arktur kernel: parent transid verify failed on 8520777674752 wanted 57362 found 57240 Nov 2 00:11:06 Arktur kernel: btrfs: corrupt leaf, bad key order: block=8520786001920,root=1, slot=2 Nov 2 00:11:06 Arktur kernel: btrfs: corrupt leaf, bad key order: block=8520786001920,root=1, slot=2 ( maybe btrfs scrub was finished ) Nov 2 06:50:46 Arktur kernel: btrfs: fixed up at 21094400 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340295811072 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340292898816 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340295815168 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340295839744 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340295872512 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340295843840 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340297310208 Nov 2 06:51:04 Arktur kernel: btrfs: fixed up at 5340297973760 Nov 2 06:51:05 Arktur kernel: btrfs: fixed up at 5340297986048 Nov 2 06:51:05 Arktur kernel: btrfs: fixed up at 5340298403840 Nov 2 08:16:45 Arktur kernel: scrub_fixup: 2 callbacks suppressed Nov 2 08:16:45 Arktur kernel: btrfs: unable to fixup at 5165489049600 Nov 2 08:16:45 Arktur kernel: btrfs: unable to fixup at 5165489053696 Nov 2 08:17:06 Arktur kernel: end_request: I/O error, dev sdg, sector 385395216 Nov 2 08:17:06 Arktur kernel: btrfs: unable to fixup at 5165519876096 Nov 2 08:17:06 Arktur kernel: btrfs: unable to fixup at 5165519880192 Nov 2 08:17:06 Arktur kernel: btrfs: unable to fixup at 5165519896576 Nov 2 08:17:06 Arktur kernel: btrfs: unable to fixup at 5165519900672 Nov 2 08:17:24 Arktur kernel: end_request: I/O error, dev sdg, sector 385395216 Nov 2 08:17:24 Arktur kernel: btrfs: unable to fixup at 5165519904768 Nov 2 08:17:40 Arktur kernel: end_request: I/O error, dev sdg, sector 385395223 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165519908864 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165532839936 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165532844032 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165519912960 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165519917056 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165519921152 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165524221952 Nov 2 08:17:40 Arktur kernel: btrfs: unable to fixup at 5165524226048 Nov 2 08:17:41 Arktur kernel: btrfs: unable to fixup at 5165541158912 Nov 2 08:17:46 Arktur kernel: btrfs: fixed up at 5064609521664 Nov 2 08:17:46 Arktur kernel: btrfs: fixed up at 5064609525760 Nov 2 08:17:46 Arktur kernel: btrfs: fixed up at 5064609554432 Nov 2 08:17:46 Arktur kernel: btrfs: fixed up at 5064609562624 Nov 2 08:17:48 Arktur kernel: end_request: I/O error, dev sdg, sector 385409567 Nov 2 08:17:48 Arktur kernel: btrfs: fixed up at 5064609800192 Nov 2
scrub: Inappropriate ioctl for device
Hallo,
I'm just playing with btrfs scrub.
Kernel 3.1 (self made)
btrfs integration-20111030 (Hugo Mills)
I have a bundle of 3 2-TByte-disks (data raid0, metadata raid1).
Since some (few) weeks one of the disks makes errors (I've reported the
problems in this mailing list).
The bundle uses the devices /dev/sdb1, /dev/sdc1 and /dev/sdg1, btrfs
filesystem show shows these informations.
Mounting doesn't work immediately; most times I have to run the mount
command three times - strange.
When I run
btrfs scrub start -r /dev/sdb1
(or another of the three disks) then I only get the error message
ERROR: getting dev info for scrub failed: Inappropriate ioctl for
device
I don't use udev, ls -l /dev/sdb1 shows
brw-r- 1 root disk 8, 17 29. Apr 1995 /dev/sdb1
Running the command via strace shows the last lines
set_thread_area({entry_number:-1 - 6, base_addr:0x401b6b80,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x401b, 8192, PROT_READ) = 0
mprotect(0x4004c000, 4096, PROT_READ) = 0
mprotect(0x4001d000, 4096, PROT_READ) = 0
munmap(0x40021000, 89277) = 0
set_tid_address(0x401b6be8) = 10400
set_robust_list(0x401b6bf0, 0xc)= 0
futex(0xbffe4c00, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0xbffe4c00, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
bffe4c10) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x4003b520, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x4003b5a0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
uname({sys=Linux, node=Arktur.wm8.hullen.de, ...}) = 0
brk(0) = 0x806d000
brk(0x808e000) = 0x808e000
mkdir(/var, 0777) = -1 EEXIST (File exists)
mkdir(/var/lib, 0777) = -1 EEXIST (File exists)
mkdir(/var/lib/btrfs, 0777) = -1 EEXIST (File exists)
stat64(/dev/sdb1, {st_mode=S_IFBLK|0640, st_rdev=makedev(8, 17), ...}) = 0
open(/dev/sdb1, O_RDWR|O_LARGEFILE) = 3
ioctl(3, 0x8400941f, 0xbffe4554)= -1 ENOTTY (Inappropriate ioctl for
device)
write(2, ERROR: getting dev info for scru..., 73ERROR: getting dev info for
scrub failed: Inappropriate ioctl for device
) = 73
close(3)= 0
exit_group(1) = ?
--
Changing the rights of /dev/sdb1 to 660 doesn't help - same nasty
behaviour.
What goes wrong?
Viele Gruesse!
Helmut
--
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: scrub: Inappropriate ioctl for device
Hallo, Ilya, Du meintest am 01.11.11: Mounting doesn't work immediately; most times I have to run the mount command three times - strange. To be able to run mount only once you have to run 'btrfs dev scan' on startup (after each reboot or just before mounting). That command has run, without any error. There seems to be another problem. When I run btrfs scrub start -r /dev/sdb1 (or another of the three disks) then I only get the error message ERROR: getting dev info for scrub failed: Inappropriate ioctl for device Scrubber runs on a mounted filesystem. df tells that the bundle of disks is mounted - there too seems to be another problem. But btrfs scrub start -r /path/to/mountpoint works - is there a mistake in the description of the command? In about 16 hours I'll know more ... Viele Gruesse! Helmut -- 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: Find RAID level, Change RAID level.
Hallo, Jordan, Du meintest am 30.10.11: I was wondering is it possible to find the RAID level currently in use by a btrfs volume, also can I change the data metadata (or either) RAID levels after creation. To see the RAID levels, use btrfs fi df /path/to/filesystem I've just run that command on my system: Data, RAID0: total=3.81TB, used=3.71TB System, RAID1: total=16.00MB, used=244.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=16.25GB, used=4.78GB And that shows what I have defined via mkfs.btrfs: ... --data raid0 --metadata raid1 What tells your system? What do you want to be installed? Viele Gruesse! Helmut -- 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: Unable to mount (or, why not to work late at night).
Hallo, Ken, Du meintest am 27.10.11: So, I dd'd everything back, and now it crashes on boot. Booting to a 2.6.x kernel (which is what I had on-hand on a USB drive) mounts it, but doesn't let me *do* anything (though it spews btrfs errors in dmesg). Getting Ubuntu 11.10 (kernel rev. 3.0.0) gives me this: [ 121.226246] device fsid d657ce6a-d353-4c2c-858a-6a1f4d9e766e devid 1 transid 217713 /dev/sda1 [ 121.232430] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.232898] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.233357] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.233365] parent transid verify failed on 100695031808 wanted 217713 found 217732 [ 121.248231] btrfs: open_ctree failed It may not please you - I have the same problem. Kernel 3.1. The first try to mount is in /etc/rc.d/rc.local. Has worked many weeks, now doesn't work. Without any message. Next try produces (in dmesg) device label MMedia devid 2 transid 57932 /dev/sdb1 parent transid verify failed on 21094400 wanted 57401 found 47987 parent transid verify failed on 21094400 wanted 57401 found 47987 parent transid verify failed on 21094400 wanted 57401 found 47987 parent transid verify failed on 21094400 wanted 57401 found 47987 parent transid verify failed on 21094400 wanted 57401 found 47987 btrfs: failed to read chunk tree on sdg1 btrfs: open_ctree failed And the third try has success: device label MMedia devid 2 transid 57932 /dev/sdb1 Very few times I don't need 3 tries, but only 2. --- What's the meaning of the 3 numbers in the parent message? Viele Gruesse! Helmut -- 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: linux v3.1 with btrfs-work: oops when deleting files
Hallo, dima, Du meintest am 26.10.11: I'm trying to rm some files, this is what I get in dmesg: [30975.249519] [ cut here ] [30975.249529] WARNING: at fs/btrfs/extent-tree.c:4588 __btrfs_free_extent+0x3b7/0x7ed() [...] [30975.249604] Pid: 12291, comm: rm Tainted: G A C 3.1.0-00057- gc82b96b-dirty #6 Can you ls the directory where the problem files are located? What would the the output? I had a very similar problem but on 3.0.x kernel when several files suddenly got corrupted. This morning I've tried kernel 3.1; you remembder my problems with 1 disk. dd if=/dev/baddisk of=/dev/zero bs=8M conv=noerror showed some bad sectors. hdparm ... --write-sector /dev/baddisk seems to repair them (I use a loop which not only tests the sector which is shown via dd but also some sectors around this one) Rebooting the machine with kernel 3.1: I could delete the old entries which seemed to contain bad sectors. Fine. Running btrfsck from the Hugo Mills git branch: still some errors - see attachment btrfsck.txt, especially the last lines; there seems to be a bug. Copying some *.mpg files from another place to the btrfs cluster: suddenly the system hangs, dmesg shows similar messages as above (from Kai Krakow). See second attachment dmesg-1.txt. halt doesn't work, reboot doesn't work, ctrl alt delete doesn't work. Reboot via power switch. Again copying: there was (within 1 file) a long pause, but then copying worked. There's still hope ... Maybe the pause caused kernel oops #3 and #4 - see attachment dmesg- 2.txt. Just to show the only big difference: now I've seen some problem(s) not related to rm but to cp. Viele Gruesse! Helmut ata1.00: configured for UDMA/100 ata1.01: configured for UDMA/100 ata1: EH complete parent transid verify failed on 5340297310208 wanted 57354 found 53683 parent transid verify failed on 5340297310208 wanted 57354 found 53683 parent transid verify failed on 5340297310208 wanted 57354 found 53683 parent transid verify failed on 5340297310208 wanted 57354 found 53683 parent transid verify failed on 5340297310208 wanted 57354 found 53683 BUG: unable to handle kernel NULL pointer dereference at 0014 IP: [c1241d76] btrfs_print_leaf+0x16/0x850 *pdpt = 22784001 *pde = Oops: [#1] Modules linked in: hisax w83781d hwmon_vid hwmon nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp xt_owner ipt_MASQUERADE iptable_nat nf_nat xt_DSCP ipt_LOG xt_multiport xt_recent xt_tcpudp ipt_REJECT iptable_filter iptable_mangle ip_tables xt_iprange nfsd exportfs xt_NOTRACK xt_state ip6t_REJECT ip6table_mangle ip6_tables x_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ipv6 crc_ccitt isdn slhc 8139too 8139cp mii e1000 aty128fb i2c_i801 piix iTCO_wdt iTCO_vendor_support intel_agp intel_gtt agpgart fuse [last unloaded: hisax] Pid: 5903, comm: btrfs-endio-wri Not tainted 3.1.0-ODSbig #1 MAXDATA */P4B EIP: 0060:[c1241d76] EFLAGS: 00010296 CPU: 0 EIP is at btrfs_print_leaf+0x16/0x850 EAX: d8941c00 EBX: d8941c00 ECX: 0001 EDX: ESI: 0002 EDI: EBP: d3379c54 ESP: d3379be8 DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 Process btrfs-endio-wri (pid: 5903, ti=d3378000 task=e4a29b80 task.ti=d3378000) Stack: 0774 0774 8ce62000 d8941c00 0850 85bca000 d3379c54 d5015070 0002 c122e2f7 00b0 c122e2f7 0070 748ce620 a807 1000 Call Trace: [c122e2f7] ? btrfs_alloc_path+0x17/0x20 [c122e2f7] ? btrfs_alloc_path+0x17/0x20 [c1239d46] __btrfs_free_extent+0x6e6/0x7c0 [c10ba9d5] ? kfree+0xe5/0x110 [c123ca26] ? run_clustered_refs+0x106/0x8a0 [c123cb4f] run_clustered_refs+0x22f/0x8a0 [c128ae00] ? btrfs_find_ref_cluster+0x60/0x1a0 [c123d259] btrfs_run_delayed_refs+0x99/0x190 [c124da86] __btrfs_end_transaction+0x66/0x1f0 [c124dc89] btrfs_end_transaction+0x19/0x20 [c125445e] btrfs_finish_ordered_io+0x2ee/0x3c0 [c1254573] btrfs_writepage_end_io_hook+0x43/0xa0 [c126ab41] end_bio_extent_writepage+0x181/0x1c0 [c1254530] ? btrfs_finish_ordered_io+0x3c0/0x3c0 [c10e6df9] bio_endio+0x19/0x30 [c1247835] end_workqueue_fn+0x125/0x180 [c17c8d6a] ? schedule_timeout+0xea/0x1d0 [c103cf70] ? cascade+0x80/0x80 [c1277b21] worker_loop+0x91/0x350 [c1028098] ? __wake_up_common+0x48/0x70 [c1277a90] ? btrfs_queue_worker+0x240/0x240 [c104b594] kthread+0x74/0x80 [c104b520] ? kthread_worker_fn+0xd0/0xd0 [c17ca93e] kernel_thread_helper+0x6/0x10 Code: 00 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 8d b4 26 00 00 00 00 55 89 e5 83 ec 6c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 c3 8b 42 14 89 d7 e8 70 3a e6 ff 89 fa 8b 40 60 89 45 dc 89 d8 e8 EIP: [c1241d76] btrfs_print_leaf+0x16/0x850 SS:ESP 0068:d3379be8 CR2: 0014 ---[ end trace 4f51358d854abcb0 ]--- parent transid verify failed on
