Hi, I''m running Ubuntu with kernel 2.6.38 on a fileserver system. One of the disks in a RAID1 configuration failed (/dev/sdc), and since then I haven''t been able to access the btrfs filesystem on the remaining disk (/dev/sdb). root@midnite:~/src/btrfs-progs-unstable# ./btrfsck /dev/sdb No valid Btrfs found on /dev/sdb root@midnite:~/src/btrfs-progs-unstable# ./btrfsck -s 1 /dev/sdb using SB copy 1, bytenr 67108864 No valid Btrfs found on /dev/sdb root@midnite:~/src/btrfs-progs-unstable# ./btrfsck -s 2 /dev/sdb using SB copy 2, bytenr 274877906944 No valid Btrfs found on /dev/sdb (This was using a btrfsck compiled from the only git repo I could find which was responding: http://git.darksatanic.net/repo/btrfs-progs-unstable.git ........ version v0.19-102-g2482539) I include below a list of commands which were executed around the time of the disk failure, attempting to mount the single remaining device (which is on /dev/sdb, and the failed disk was on /dev/sdc). I''m pretty sure I didn''t destroy anything in the process, but who knows - hence why I include the list. Any help appreciated in recovering the partition on /dev/sdb and accessing the data. Thanks, Dan G 527 btrfs device scan 610 btrfs device scan 611 btrfs device show 612 btrfs fi df 613 btrfs fi df -h 614 btrfs fi df nuvat 615 btrfs fi show 648 btrfs device scan 649 btrfs 650 btrfs fi df 651 btrfs fi df nuvat 652 btrfs fi show 653 btrfs fi df /nuvat/ 654 btrfs fi show 665 vi /usr/share/initramfs-tools/modules.d/btrfs 1136 btrfs 1137 btrfs device scan 1139 btrfs device scan 1140 man btrfs 1141 btrfs device scan /dev/sdc 1143 btrfs filesystem df /nuvat/ 1144 btrfsck 1145 btrfsck /dev/sdc 1146 btrfsck /nuvat 1147 btrfsctl --help 1148 btrfsctl -a 1149 btrfsctl -A /dev/sdc 1150 btrfs-show 1197 btrfs-show 1198 btrfsck 1199 btrfsck /dev/sdb 1200 btrfsck /dev/sdc 1201 btrfsck /dev/sdv 1202 btrfsck /dev/sdb 1203 btrfstune 1204 btrfsctl 1205 btrfsctl -a 1286 btrfs-vol 1287 btrfs filesystem show 1290 btrfs device scan 1292 btrfsck 1293 btrfsck /dev/sdb 1299 btrfsctl 1300 btrfsctl -a 1304 btrfsck -h 1305 btrfsck --help 1306 btrfsck 1307 btrfsck /dev/sdc 1308 btrfsck /dev/sdb 1309 btrfs-show 1310 btrfs-show nuvat 1311 btrfs-vol 1312 dpkg -l | grep btrfs 1313 apt-get install btrfs-tools 1314 btrfsctl 1315 btrfsctl -c 1316 btrfsctl -A 1317 btrfsctl -A /dev/sdb 1318 btrfsctl -d 1319 btrfsctl -d /nuvat/ 1320 btrfsctl -d /dev/sdb 1321 btrfs-show 1322 btrfs-show --help 1323 btrfs-show /dev/sdb 1326 btrfs-vol 1327 btrfs-vol -a 1328 btrfs-vol -a /nuvat 1329 btrfs-vol -a asdasd /nuvat 1330 btrfs-vol -a missing /nuvat 1331 btrfs-vol -a /dev/sdc /nuvat 1332 btrfs-vol -a /dev/sdb /nuvat 1334 btrfs-vol -a missing /nuvat 1335 btrfs 1336 btrfs device /dev/sdc /nuvat 1337 btrfs device add /dev/sdc /nuvat 1338 btrfs device delete /dev/sdc /nuvat 1339 btrfs fi show 1340 btrfs fi show /nuvat 1341 btrfs fi show nuvat 1342 btrfs filesystem show nuvat 1343 btrfs filesystem show 1344 btrfsctl -a 1345 btrfs device scan 1346 btrfs filesystem show all 1348 btrfs-show /dev/sdb 1352 btrfsck /dev/sdb 1355 btrfsck 1356 btrfsck -s 1357 btrfsck -s 1 1358 btrfsck -s 1 /dev/sdb 1360 apt-cache search btrfs 1361 btrfs filesystem show 1374 btrfs 1375 btrfs device scan 1376 btrfs fi show 1377 history | grep btrfs 1387 btrfs-vol 1388 btrfsck /dev/sdb 1389 btrfs subvolume 1390 btrfs fi show 1391 dpkg -l | grep btrfs 1392 apt-cache search btrfs 1393 git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git/btrfs-progs__git 1394 cd btrfs-progs__git/ 1398 ./btrfs device scan 1399 ./btrfsck 1400 ./btrfsck /dev/sdb 1401 ./btrfsctl -a -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
C Anthony Risinger
2012-Jan-03 21:49 UTC
Re: Btrfs partition lost after RAID1 mirror disk failure?
On Tue, Jan 3, 2012 at 8:44 AM, Dan Garton <dan.garton@gmail.com> wrote:> > [...] > 1327 btrfs-vol -a > 1328 btrfs-vol -a /nuvat > 1329 btrfs-vol -a asdasd /nuvat > 1330 btrfs-vol -a missing /nuvat > 1331 btrfs-vol -a /dev/sdc /nuvat > 1332 btrfs-vol -a /dev/sdb /nuvat > 1334 btrfs-vol -a missing /nuvat > [...]these look destructive to me ... adding the wrong devices and the existing devices back to the current array? IIRC you should have `-r missing`, but in general, do not use the btrfsctl utility at all -- it won''t have as much visibility/exception-handling/recovery as the `btrfs` utility. at what point did your FS become inaccessible? your command history suggest it was working until shortly after these commands ... :-( -- C Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, thanks for the reply. Yes, I agree, after going back over the commands, those ones you highlighted seem very suspicious.... These commands were executed weeks ago amid a fair amount of confusion. But yes, I think that you are right - from memory the FS became inaccessible at about the time you mention. I would say that was the best theory as regards this problem. Assuming that this is the case, do I stand a chance of retrieving that volume and accessing that data again? Or does "destructive" imply total loss? (In which case, I''ll cut my losses....) On 3 January 2012 21:49, C Anthony Risinger <anthony@xtfx.me> wrote:> > On Tue, Jan 3, 2012 at 8:44 AM, Dan Garton <dan.garton@gmail.com> wrote: > > > > [...] > > 1327 btrfs-vol -a > > 1328 btrfs-vol -a /nuvat > > 1329 btrfs-vol -a asdasd /nuvat > > 1330 btrfs-vol -a missing /nuvat > > 1331 btrfs-vol -a /dev/sdc /nuvat > > 1332 btrfs-vol -a /dev/sdb /nuvat > > 1334 btrfs-vol -a missing /nuvat > > [...] > > these look destructive to me ... adding the wrong devices and the > existing devices back to the current array? IIRC you should have `-r > missing`, but in general, do not use the btrfsctl utility at all -- it > won''t have as much visibility/exception-handling/recovery as the > `btrfs` utility. > > at what point did your FS become inaccessible? your command history > suggest it was working until shortly after these commands ... :-( > > -- > > C Anthony-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
C Anthony Risinger
2012-Jan-07 06:22 UTC
Re: Btrfs partition lost after RAID1 mirror disk failure?
On Wed, Jan 4, 2012 at 2:30 PM, Dan Garton <dan.garton@gmail.com> wrote:> > Assuming that this is the case, do I stand a chance of retrieving that > volume and accessing that data again? > Or does "destructive" imply total loss? (In which case, I''ll cut my > losses....)unfortunately i really don''t know enough to advise ... i did similar actions a long time ago while experimenting for an initcpio-based rollback utility, but in my case the FS was a dummy/loopback, so i just burned it. my only suggestion would be to try Josef''s readonly recovery/slurp utility and maybe you can pull some data off, since my completely uninformed guess is the structures are 99% intact, but your UUIDs no longer match, or internal top-level pointers to wrong locations, etc etc. perhaps someone more familiar with actual internals can be of more help -- good luck. -- C Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html