Digging up an old thread..

I had opportunity yesterday to examine a "QNAP TS-209 Pro" here.

This is a two-drive RAID1 NAS box, Linux/ARM based on the inside, with dual hot-pluggable SATA slots, several external USB2 ports, and GigEthernet. The software inside is positively *ancient*.. a 2.6.12 Linux kernel, but with several customizations.

The SATA controller is a Marvell 6081 chip, which I know a little bit about, and the software is creaking along with Marvell's proprietary driver for it. Which was really the only option, back in the 2.6.12 days.

With very fast drives, it manages > 30MBytes/sec read speeds (those same drives can do > 110MBytes/sec in a faster machine with the same controller chip + my newer driver).

The GigE port is purely for marketing purposes, as the system barely manages 50-60 mbits/sec over it when reading data from the box. It might be faster in the other direction, but I was on a non-destructive mission with it.

Speaking of that mission: The owner had originally installed dual 750GB drives, but needed more space. So he had installed new 1GB drives, one at a time, allowing the RAID1 to sync up individually from the old drives.

That part worked fine, to a point. The software auto-partitioned his 1GB drives to include all available space just fine, but did not automatically enlarge the RAID or filesystem data structures to actually use the space.

So I popped the drives out and into a larger/faster system, and after a binary backup of the RAID, we looked at fixing matters.

mdadm --grow --size max /dev/md0 worked like a charm -- the raid absorbed the extra 250GB without any fuss.

But getting the filesystem to see/use it was another matter. Doing this requires the resize2fs command, which was missing from the box.

When logged into the NAS, it reported ext3 as the filesystem type. But in our bigger full Linux box, the kernel identified it as ext4 (!). Quite the feat for something created under a 2.6.12 kernel, long before ext4 had even been conceived.

It turns out that their custom kernel included patches to add extents to ext3, a feature that nowadays belongs only to its newer cousin. But the real problem is that the on-disk layout/structures for those extents has been changed since the experimental days way back when.

Which means that no standard kernel, regardless of age, can actually reliably access the data stored on those drives. Apart from the custom kernel the box is shipped with, that is. But the box is missing the critical resize2fs command which is necessary for adding space to a filesystem (be it ext2, ext3, or ext4).

Which brought us to a practical dead-end. My buddy is now copying his data off of the NAS onto a USB drive, after which he'll reinit the NAS from scratch to incorporate the full TB capacity of his new drives, and will then copy the data back onto it again. 22-23 hours per copy for the 550GB of data he has.

There is some GPL source code on the company site, for an older release of their firmware, but it doesn't build with the modern GNU tools on my notebook here. If we spent another day on it, we could eventually succeed in rebuilding the tools, and obtain a working (on the box itself) copy of resize2fs for it, but it just didn't seem worthwhile.

Instead, all I got was this story..

Cheers