Getting files out of XFS with 64kb block size

Question

I've been on a mission to recover files from one of my 2 perfectly working, non-corrupted, non-encrypted NAS drives that used to be in RAID 1. The NAS was Patriot Javelin S4, which (as I found from my research) uses Promise Fasttrack fake raid controller.

Information is very scarce on this, so for googlers in the same situation here are some facts about this NAS:

• RAID controller: Promise FastTrack (FakeRaid)
• Volume system: LVM2
• Filesystem: XFS with 64kb block size (65536 bytes)
• Arch: 800MHz AMCC PowerPC processor, 256MB RAM (thanks to Matthew's research)

I only had Windows 10 and MacOS computer when doing this, and I found no software capable of mounting XFS in LVM2 volume (with 1 exception, more on this below). I had to take out my old netbook Acer Aspire One, and install puppy linux on it (specifically lxpup flavor).

On puppy linux I managed to mount this file system using a tool called dmraid. This tool has a way of mounting a pdc volume, which is its id for Promise FastTrack. Once I managed to jump through some hoops mounting it, I gained access to the actual XFS filesystem, and to my dismay, it turned out to be 64kb block size.

This is where I started googling things like "read xfs 64kb block size" and getting nowhere. Only a few answers that say: "linux can't read block sizes bigger than 4kb, unless you patch the kernel". I have no idea how to patch the kernel, and I'm baffled that there isn't any kind of emulation to allow this.

I mentioned 1 exception among apps that can't read this partition on Win/Mac. That exception was ufsexplorer. It's a $100 app, it was able to seamlessly show me the files. I copied a few files proving that it works, but the trial version only allows copying tiny files.

I refuse to believe that there isn't a free open source tool out there of any level of complexity that can't help me read 64kb xfs.

My question is: does anybody know of any such tool? Any specific instructions on how to get the data using one or more tools, or kernel patching, or something else (free) are greatly appreciated.

One more point: I would highly prefer to not have to create local images of these drives (unless that's the only way). After all, it's 2TB of data, I may not have this much space.

P.S. If there's a known linux I can install on my Acer that can read 64kb xfs, that's a viable solution too.

Update 1: I just learned about https://www.cgsecurity.org/wiki/TestDisk. Might be worth a shot. Will report back once I had time to try it.

Update 2: TestDisk seems to be recognizing the presence of XFS partition, but I'm not sure how to proceed form there. I don't see a way to extract a file, so I just abandoned it for now, and trying the qemu approach in Matthew's answer.

Answer 1

I've done a bit of research into your problem. Not easy but looks feasible.

The area of code breaking you is this (well, in newer kernels): fs/xfs/libxfs/xfs_sb.c

271         /*
272          * Until this is fixed only page-sized or smaller data blocks work.
273          */
274         if (unlikely(sbp->sb_blocksize > PAGE_SIZE)) {
275                 xfs_warn(mp,
276                 "File system with blocksize %d bytes. "
277                 "Only pagesize (%ld) or less will currently work.",
278                                 sbp->sb_blocksize, PAGE_SIZE);
279                 return -ENOSYS;
280         }

It basically requires that the XFS block size be at least equal to the systems page size.

This means two things.

1. This is a workaround of a bug previously not known about.
2. The systems page size originally was 64k.

I went and checked a really old kernel (EL4) and that restriction above was still there. This means its fundamentally not feasible to do what you want to do on your architecture (x86).

Given you provided the name of the NAS I did some googling and discovered this: http://www.techwarelabs.com/patriot-javelin-s4-network-attached-storage/2/

Which implies it uses a PPC CPU.

The hardware of the Javelin is more than capable of handling additional roles. It is essentially an embedded Linux system with a 800 MHz AMCC PowerPC processor and 256 MB of RAM.

Indeed, on PowerPC kernels can be built to use either 64k pages or 4k pages. This would explain why the block is 64k and also why you cant run the filesystem on your machine, where it worked on its own NAS before.

If you want to try to open the filesystem -- I think your best option is to run a virtual machine instance in a hypervisor using PPC64LE (I think thats the actual architecture of that CPU), Fedora build their PPC64LE with 64k pages.

https://alt.fedoraproject.org/alt/

You can use qemu to do this. This guy seems to give some (not tested) instructions on how you'd go about doing this.

https://rwmj.wordpress.com/tag/ppc64le/

From there, directly expose the disk(s) in the VM and do your normal dmraid/lvm/mount to get access to the drive.