9

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.

  • I see two solutions, build your own custom kernel or make an image with your xfs partition and try to open it under windows by fs-driver.org – Alexander Tolkachev May 29 '17 at 18:07
  • @AlexanderT Hi, thanks for responding. Any links about custom kernel? Also, is there perhaps a way to clone the drive into my mac's drive while converting the filesystem on-the-fly? And to be clear: I have the NAS drive hooked up via SATA -> USB converter, so I can plug it directly into windows or mac without making an image. – Max Chernyak May 29 '17 at 18:18
  • Try and see if xfsdump help. – Martian May 30 '17 at 14:56
  • > it turned out to be 64kb block size. Elaborate on how you came to this conclusion, please – poige May 31 '17 at 16:38
  • 1
    I see. Well, the thing I'd go for being in your shoes is writing to corresponding mail list: xfs.org/index.php/XFS_email_list_and_archives – poige Jun 1 '17 at 1:48
8
+200

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.

  • I will report back as soon as I had time to look into qemu approach. Looks very hopeful, appreciate the time you put into this Matthew. – Max Chernyak Jun 2 '17 at 5:07
  • Currently I'm astuck trying to run virt-builder fedora-25 --arch ppc64le -o fedora-25-ppc64le.img. I am on puppy linux and getting "supermin: could not detect package manager used by this system or distro." – Max Chernyak Jun 6 '17 at 21:44
  • Use a fedora distro to do it. – Matthew Ife Jun 6 '17 at 21:47
  • I haven't had a chance to finish this attempt yet, but I'm giving you the bounty. I hope I can still follow up as I'm working towards it. – Max Chernyak Jun 7 '17 at 17:46
  • @hakunin I was able to both format and mount a 64kb xfs filesystem in a ppc64le architecture as I suggested you do earlier this week so I know this will work. – Matthew Ife Jun 7 '17 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.