Re: USB upgrade fun
On Sun, 29 Oct 2017, at 06:02 PM, Qu Wenruo wrote: > If so, mount it, do minimal write like creating an empty file, to update > both superblock copies, and then try fix-device-size. Tried that, and it didn't work. Made a recording: https://youtu.be/SFd3QscNT6w -- 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: USB upgrade fun
On Sat, 28 Oct 2017, at 03:58 PM, Qu Wenruo wrote: > Don't get confused with the name, to use "fix-dev-size" you need to run > "btrfs rescue fix-dev-size" [hendry@nuc btrfs-progs]$ sudo ./btrfs rescue fix-device-size /dev/sdc1 warning, device 2 is missing ERROR: devid 2 is missing or not writeable ERROR: fixing device size needs all device(s) present and writeable [hendry@nuc btrfs-progs]$ lsblk -f NAME FSTYPE LABELUUID MOUNTPOINT sda ├─sda1 vfat0C95-8576/boot └─sda2 btrfs c5f98288-5ab3-4236-b00e-f2cd15c0616d / sdb sdc └─sdc1 btrfs extraid1 5cab2a4a-e282-4931-b178-bec4c73cdf77 [hendry@nuc btrfs-progs]$ lsblk -f NAME FSTYPE LABELUUID MOUNTPOINT sda ├─sda1 vfat0C95-8576/boot └─sda2 btrfs c5f98288-5ab3-4236-b00e-f2cd15c0616d / sdb └─sdb1 btrfs extraid1 5cab2a4a-e282-4931-b178-bec4c73cdf77 sdc └─sdc1 btrfs extraid1 5cab2a4a-e282-4931-b178-bec4c73cdf77 [hendry@nuc btrfs-progs]$ sudo ./btrfs rescue fix-device-size /dev/sdc1 Couldn't setup extent tree Couldn't setup device tree ERROR: could not open btrfs [hendry@nuc btrfs-progs]$ sudo ./btrfs rescue fix-device-size /dev/sdb1 leaf parent key incorrect 1320477425664 ERROR: could not open btrfs [hendry@nuc btrfs-progs]$ sudo mount -o degraded /dev/sdb1 /mnt/raid1/ mount: /mnt/raid1: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error. Still unable to mount. Damn. Maybe I'm chasing a red herring? Here are the relevant kernel logs: Oct 29 10:56:45 nuc kernel: sd 2:0:0:0: [sdb] Attached SCSI disk Oct 29 10:57:32 nuc kernel: BTRFS info (device sdc1): allowing degraded mounts Oct 29 10:57:32 nuc kernel: BTRFS info (device sdc1): disk space caching is enabled Oct 29 10:57:32 nuc kernel: BTRFS info (device sdc1): has skinny extents Oct 29 10:57:33 nuc kernel: BTRFS error (device sdc1): super_total_bytes 4000795746304 mismatch with fs_devices total_rw_bytes 4000795749888 Oct 29 10:57:33 nuc kernel: BTRFS error (device sdc1): failed to read chunk tree: -22 Oct 29 10:57:33 nuc kernel: BTRFS error (device sdc1): open_ctree failed Nonetheless if I reboot to 4.4, I can still mount. However my root is bizarrely out of space or inodes so journalctl et al is unusable. Kind regards, -- 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: USB upgrade fun
On Fri, 13 Oct 2017, at 09:42 AM, Kai Hendry wrote: > It probably is... since when I remove my new 4TB USB disk from the > front, I am at least able to mount my two 2x2TB in degraded mode and see > my data! Just a follow up. I have not been of late been able to mount my data, even in degraded mode. However someone on #btrfs suggested I try an older Linux kernel & I also found https://www.spinics.net/lists/linux-btrfs/msg69905.html to reaffirm my suspicions. Low and behold I can mount with an older kernel (linux-4.4.3-1-x86_64.pkg.tar.xz) !! But if I reboot into 4.13.9-1-ARCH, no worky: [ 489.139903] BTRFS warning (device sdb1): devid 3 uuid e5f03f81-35e7-4a29-9608-bd78864cc0ad is missing [ 489.524334] BTRFS info (device sdb1): bdev (null) errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 [ 489.524367] BTRFS info (device sdb1): bdev /dev/sdb1 errs: wr 13361, rd 31990017, flush 155, corrupt 0, gen 0 [ 502.934069] BTRFS warning (device sdb1): missing devices (1) exceeds the limit (0), writeable mount is not allowed [ 502.980748] BTRFS error (device sdb1): open_ctree failed Does anyone know how I can track the progress of "--fix-dev-size"? It doesn't seem part of btrfs-progs 4.13-1... -- 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: USB upgrade fun
Thank you Austin & Chris for your replies!
On Fri, 13 Oct 2017, at 01:19 AM, Austin S. Hemmelgarn wrote:
> Same here on a pair of 3 year old NUC's. Based on the traces and the
> other information, I'd be willing to bet this is probably the root cause
> of the issues.
It probably is... since when I remove my new 4TB USB disk from the
front, I am at least able to mount my two 2x2TB in degraded mode and see
my data!
So I am not quite sure what to do now.
I don't trust USB hubs.
On a different NUC I've noticed I can't charge my iPhone anymore!
https://mail-archive.com/linux-usb@vger.kernel.org/msg95231.html So...
is there any end in sight for the "USB power" problem? Does USB-C /
Thunderbolt address this issue? :(
Try return my new 4TB to Amazon and find an externally powered one
> > merely the Btrfs signature is wiped from the deleted device(s). So you
> > could restore that signature and the device would be valid again;
Wonder how would you do that, in order to have a working snapshot that I
can put in cold storage?
Nonetheless I hope the btrfs developers can make it possible to remove a
RAID1 drive, to put in cold storage use case, without any pfaffing.
I ran that debug info: https://s.natalian.org/2017-10-13/btrfs-reply.txt
To summarise:
* sdb - new 4TB disk that makes my raid1 unmountable atm when connected
* sd{c,d} - old 2tb
Here's the accompanying dmesg.txt
https://s.natalian.org/2017-10-13/dmesg.txt sorry, it might be difficult
to follow since I was moving the 4TB between the front ports and such.
Kind regards,
--
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: USB upgrade fun
A guy on #btrsfs suggests:
15:09 hendry: super_total_bytes 8001581707264 mismatch with
fs_devices total_rw_bytes 8001581710848 that one is because unaligned
partitions, 4.12 - 4.13 kernels are affected (at least some versions)
However I rebooted into 4.9.54-1-lts and I have the same issue.
super_total_bytes 8001581707264 mismatch with fs_devices total_rw_bytes
8001581710848
https://s.natalian.org/2017-10-12/1507775104_2548x1398.png
Any ideas what I can do now? I am getting rather nervous!
Btw I checked sudo btrfs check -p /dev/sd{b,c,d}1 and they are all fine.
Just can't mount my data! :(
Hope you can help me,
--
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: USB upgrade fun
On Tue, 10 Oct 2017, at 10:06 AM, Satoru Takeuchi wrote: > Probably `btrfs device remove missing /mnt/raid1` works. That command worked. Took a really long time, but it worked. However when I unmounted /mnt/raid1 and tried mounting it again, it fails! :( https://s.natalian.org/2017-10-11/btrfs.txt mount: /mnt/raid1: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error. "open_ctree failed" is back... sigh... Any tips? I'm going to check the disks one by one and I'll reboot the server a little later. -- 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
USB upgrade fun
Hi there, My /mnt/raid1 suddenly became full somewhat expectedly, so I bought 2 new USB 4TB hard drives (one WD, one Seagate) to upgrade to. After adding sde and sdd I started to see errors in dmesg [2]. https://s.natalian.org/2017-10-07/raid1-newdisks.txt [2] https://s.natalian.org/2017-10-07/btrfs-errors.txt I assumed it had to perhaps with the USB bus on my NUC5CPYB being maxed out, and to expedite the sync, I tried to remove one of the older 2TB sdc1. However the load went crazy and my system went completely unstable. I shutdown the machine and after an hour I hard powered it down since it seemed to hang (it's headless). Sidenote: I've since learnt that removing a drive actually deletes the contents of the drive? I don't want that. I was hoping to put that drive into cold storage. How do I remove a drive without losing data from a RAID1 configuration? After a reboot it failed, namely because "nofail" wasn't in my fstab and systemd is pedantic by default. After managing to get it booting into my system without /mnt/raid1 I faced these "open ctree failed" issues. After running btrfs check on all the drives and getting nowhere, I decided to unplug the new drives and I discovered that when I take out the new 4TB WD drive, I could mount it with -o degraded. dmesg errors with the WD include "My Passport" Wrong diagnostic page; asked for 1 got 8 "Failed to get diagnostic page 0xffea" which raised my suspicions. The model number btw is WDBYFT0040BYI-WESN Anyway, I'm back up and running with 2x2TB (one of them didn't finish removing, I don't know which) & 1x4TB. [1] https://s.natalian.org/2017-10-08/usb-btrfs.txt I've decided to send the WD back for a refund. I've decided I want keep the 2x2TB and RAID1 with the new 1x4TB disk. So 4TB total. btrfs complains now of "Some devices missing" [1]. How do I fix this situation? Any tips how to name this individual disks? hdparm -I isn't a lot to go on. [hendry@nuc ~]$ sudo hdparm -I /dev/sdb1 | grep Model Model Number: ST4000LM024-2AN17V [hendry@nuc ~]$ sudo hdparm -I /dev/sdc1 | grep Model Model Number: ST2000LM003 HN-M201RAD [hendry@nuc ~]$ sudo hdparm -I /dev/sdd1 | grep Model Model Number: ST2000LM005 HN-M201AAD Ok, thanks. Hope you can guide me, -- 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 device delete /dev/sdc1 /mnt/raid1 user experience
On Tue, 7 Jun 2016, at 07:10 PM, Austin S. Hemmelgarn wrote: > Yes, although you would then need to be certain to run a balance with > -dconvert=raid1 -mconvert=raid1 to clean up anything that got allocated > before the new disk was added. I don't quite understand when I should run this command. Before I take it out? Once I take it out? One the new one is added? And why doesn't it do this automatically? =) -- 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 device delete /dev/sdc1 /mnt/raid1 user experience
Sorry I unsubscribed from linux-btrfs@vger.kernel.org since the traffic was a bit too high for me. On Tue, 7 Jun 2016, at 11:42 AM, Chris Murphy wrote: > Your command turned this from a 3 drive volume into a 2 drive volume, > it removed the drive you asked to be removed. I actually had 2 drives to begin with, but it wouldn't allow me to delete the drive without adding a new one, so I had 3 drives. I think I've confused you by my talk of "RAID-1 over 3 drives". I am not sure why RAIDX terminology is so confusing. All I want is for the data on one drive to be mirrored across them all. So if I add X drives, I want to X exact copies. But IIUC this changes the RAID level and everyone gets confused what I am talking about. > You're definitely missing something but once you understand how it > actually works, it'll be interesting if you have suggestions on how > the existing documentation confused you into making this mistake. Summary: I issued the remove command when I should have just removed it physically IIUC. If I was to do this again, I would unmount the raid1 mount. Take a disk physically out and then add the new one. So yes, it would be degraded but then as you mention, the newly drive will sort it out. One would hope. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs device delete /dev/sdc1 /mnt/raid1 user experience
On Mon, 6 Jun 2016, at 10:16 PM, Austin S. Hemmelgarn wrote: > Based on the fact that you appear to want to carry a disk to copy data > more quickly than over then internet, then what you've already done plus > this is the correct way to do it. The trouble is the way I ended up doing it: 1) Replacing it with a bigger disk 2) Deleting the disk 3) btrfs send /mnt/raid1/snapshot | btrfs receive /mnt/onetb/ This took almost **an entire day** over USB3 spinning disks ! My expectation was that I could quickly remove a mirrored disk, replace that disk and hand carry the disk I removed. btrfs shouldn't remove data from the disk I removed. Kind regards, -- 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 device delete /dev/sdc1 /mnt/raid1 user experience
Hi there, I planned to remove one of my disks, so that I can take it from Singapore to the UK and then re-establish another remote RAID1 store. delete is an alias of remove, so I added a new disk (devid 3) and proceeded to run: btrfs device delete /dev/sdc1 /mnt/raid1 (devid 1) nuc:~$ uname -a Linux nuc 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux nuc:~$ btrfs --version btrfs-progs v4.5.3 nuc:~$ sudo btrfs fi show /mnt/raid1/ Label: 'extraid1' uuid: 5cab2a4a-e282-4931-b178-bec4c73cdf77 Total devices 2 FS bytes used 776.56GiB devid2 size 931.48GiB used 778.03GiB path /dev/sdb1 devid3 size 1.82TiB used 778.03GiB path /dev/sdd1 nuc:~$ sudo btrfs fi df /mnt/raid1/ Data, RAID1: total=775.00GiB, used=774.39GiB System, RAID1: total=32.00MiB, used=144.00KiB Metadata, RAID1: total=3.00GiB, used=2.17GiB GlobalReserve, single: total=512.00MiB, used=0.00B First off, I was expecting btrfs to release the drive pretty much immediately. The command took about half a day to complete. I watched `btrfs fi show` to see size of devid 1 (the one I am trying to remove) to be zero and to see used space slowly go down whilst used space of devid 3 (the new disk) slowly go up. Secondly and most importantly my /dev/sdc1 can't be mounted now anymore. Why? sudo mount -t btrfs /dev/sdc1 /mnt/test/ mount: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. There is nothing in dmesg nor my journal. I wasn't expecting my drive to be rendered useless on removing or am I missing something? nuc:~$ sudo fdisk -l /dev/sdc Disk /dev/sdc: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: gpt Disk identifier: 19938642-3B10-4220-BF99-3E12AF1D1CF6 Device StartEndSectors Size Type /dev/sdc1 2048 1953525133 1953523086 931.5G Linux filesystem On #btrfs IRC channel I'm told: hendry: breaking multi-disk filesystems in half is not a recommended way to do "normal operations" :D I'm still keen to take a TB on a flight with me the day after tomorrow. What is the recommended course of action? Recreate a mkfs.btrfs on /dev/sdc1 and send data to it from /mnt/raid1? Still I hope the experience could be improved to remove a disk sanely. Many thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
