XFS partition unreadable

M

MrPercent

I'm using FreeeBSD 9.0-RELEASE-p3, and have compiled the xfsprogs in the ports library, to attempt to repair and mount a couple of XFS partitions on a disk rescued from a Buffalo Linkstation.

I can see two XFS partitions: (/dev/ada2s6 is inside an EBR)
Code: 
{root@orac} file - < /dev/ada2s2
/dev/stdin: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
{root@orac} file - < /dev/ada2s6
/dev/stdin: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
{root@orac}

I can run xfs_check on both, but return, with no output.
When I run xfs_repair, they both display
Code: 
{root@orac} xfs_repair /dev/ada2s2
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0

And then it hangs, eating no CPU, doing no system calls. When I mount the partitions, they mount cleanly, but again, when I go into them, and 'ls', computer crashes.

I suspect they (and more importantly, the data they contain) may be beyond recovery, but would like a second option, or other helpful pointers.

Ultimately want to put data on zfs, and bring disk into zfs pool.

Thanks in advance,

Mr%
 
The hanging or crashing might be due to bad blocks on the disk. You could try to use sysutils/ddrescue to get a "clean" copy. Then try to repair the copy with xfs_repair.
 
XFS is a strange duck. The port that SGI did before they went bankrupt and sold themselves to Rackable Systems was buggy. Even the tool chain was buggy. It was less buggy than most of the other filesystems that were released in that time frame such as IBM's HFS, but I found huge gaping bugs in the initial XFS port to Linux that the SGI XFS team was, like, "So?". Over the past couple of years Red Hat realized that putting all their eggs in the BTRFS basket (their buggy clone of ZFS) was crazy because BTRFS will never have the pure raw streaming performance that XFS has (remember, XFS was designed for streaming huge scientific datasets at high speeds and is optimized for that purpose), and has put a lot of work into fixing huge enormous bugs in both the XFS filesystem and in the userland tools such as xfs_repair, whose original SGI port was notoriously incompetent. *Finally* the XFS tool chain is at a stage where I consider it stable and usable (remember, it was 2004 when I first used XFS for production work, and found it to be fast as the blazes and the only thing that would actually work for what we were doing -- video streaming -- but the tool chain was atrocious, you basically couldn't fix an XFS filesystem once it got busted because the amount of memory required to do so was beyond the memory capacity of any computer that existed at that time). Unfortunately the only way I know of to get those tools is via the very latest Red Hat Fedora Linux distribution (I think they're up to Fedora 17 now?), which you might try running in VirtualBox or KVM on your FreeBSD host to see if it is as baffled by the XFS filesystem as the BSD tools in ports are..

Note that I don't use XFS for production purposes even on Linux unless absolutely necessary (such as requiring massive streaming performance). Looking at the kernel GIT commit comments for changes to the XFS filesystem over the 2.6.3x timeframe was rather terrifying, and current stable Linux distributions do not have most of those changes in them. But then, I'm a major paranoic when it comes to data integrity, which is one reason why I'm using ZFS on FreeBSD... while not perfect, it's a heckuva lot better than anything else out there as far as I can tell. Just too slow for some purposes, sigh...

So anyhow: Try the very latest Linux toolchain on the very latest Fedora Linux via your favorite virtualization system. There were some huge patches in both the kernel-land filesystem and the user-land toolchain quite recently to improve its ability to recover from errors. This probably wasn't what you wanted to hear -- i.e., that there's some changes that haven't been merged into the FreeBSD XFS toolchain -- but so it goes.
 
Many thanks to both posters. I did the ddrescue (which took somewhile!), and it didn't really complain of any bad sectors etc. I re-ran the tools on the newly created disk/partions, and same deal.

I think my mext step is to put the drive back into whence it came from, and try and de-install the Japanese firmware, which has lead me here. I suspect this will be quicker than VM/Fedora'ing but I may give that a try too.

Many thanks again,

MrPercent.
 
Quick update. Managed to read data from XFS disk, using the linkstation. It appears whilst there is support for XFS within the kernel, it is as badtux says, somewhat limited.

Having said that, the whole experience with FreeBSD has been fantastic, google for commands, that just work. Most impressed.

regards, Mr%
 
You must log in or register to reply here.
Back
Top