NSA320 maximum drive size

Sorry if this should be a Debian question, but the Zyxel NSA320 specs list the maximum drive size of 3TB. I'm wondering if this is a limitation by the hardware, or if the new uboot / Linux kernel allows a larger drive size than that.

Anybody have any ideas on this? Thanks!

dhargens,

> Zyxel NSA320 specs list the maximum drive size of
> 3TB. I'm wondering if this is a limitation by the
> hardware, or if the new uboot / Linux kernel
> allows a larger drive size than that.

There should be no HDD size limit for the Zyxel NSA320 with the new u-boot and kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Most likely 16TiB limit for block devices generally with 32-bit ARM Linux Kernel.

Starting to wish I had a 18TB drive to do some tests with, I'd bet anything some older SATA controllers will have issues with drives above a certain size too but don't know of any so far.

> Most likely 16TiB limit for block devices
> generally with 32-bit ARM Linux Kernel.
>
> Starting to wish I had a 18TB drive to do some
> tests with, I'd bet anything some older SATA
> controllers will have issues with drives above a
> certain size too but don't know of any so far.

Yes! I should've said "there is no greater than 2TB limit". 2TB was the limit with stock u-boot in the old days.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

2TB limit for MBRs though that can usually be worked around unless you're using a truly ancient kernel.
2TB limit for some ancient sata chips, old usb->sata converters in particular.
16TiB for 32-bit ARM and other 32-bit architectures that tie block size to page size and force 4K pages (2^32 * 4K = 16TiB)

The last restriction effects mdadm devices too. There are some out-of-tree patchsets out there that work around that limitation but none ever made it into the mainline kernel.

> 2TB limit for MBRs though that can usually be
> worked around unless you're using a truly ancient
> kernel.

That 2TB limit was for old stock u-boot which does not know GPT. IOW, so you can't boot with box with the kernel files on a 3TB partition. However, the kernel would not have that limit after it starts.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

mainline 32-bit ARM kernels like the armel and armhf (even the LPAE version) used with Debian have a 16TiB limit for block devices which includes drives and logical devices like mdadm arrays.

You get a lot of weird results if you try using using such a device since some programs/calls will report the correct size/etc but you end up with IO errors trying to access past the 16TiB limit. I thought I had posted some examples somewhere but the only thing I found was an example of mkfs.ext4 failing with one:

root@debian# mkfs.ext4 -O 64bit /dev/md10
mke2fs 1.44.5 (15-Dec-2018)
/dev/md10 contains a xfs file system
Proceed anyway? (y,N) y
Creating filesystem with 5826563584 4k blocks and 364161024 inodes
Filesystem UUID: 820821cf-2489-413a-8b34-980d45e01f0c
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
        2560000000, 3855122432, 5804752896

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): mkfs.ext4: Attempt to read block from filesystem resulted in short read
        while trying to create journal

Many/Most NAS vendors ship kernels for some of their devices with tweaks to get around this limitation by using larger data types for storing the block addresses etc. This is typically paired with tweaks to support larger memory pages supported by those particular chips (which tends to break modern binaries because of linker issues).

Over the years some people have tried submitting versions of those patches to the mainline kernel but they haven't been accepted.
ex: https://lore.kernel.org/linux-arm-kernel/20200611162117.GY1551@shell.armlinux.org.uk

I recently got way deeper into the topic than any sane person should creating a Buildroot-based firmware for some AL-314 Buffalo devices using a kernel built from the GPL source since mainline support is lacking.