Volume larger than 16TB (859)

[hans2011]

wow thnx - just 2 b sure I understood right. I will re-create the RAID w/ all the 8 discs and have more then 16 TB available? If yes, I´ll do that 4 sure ...

[Dreamweaver]

I'll get my money back from the dealer. That Linux can't support Filesystem Sizes > 16 TB? WTF!
And why QNAP advertises "new Firmware" - so that you can now install 3 TB Drives? You should warn your customers! Also you can warn in your web-interface!!!

QNAP, be honest with yourself and correct your commercials!!

[nnsqnap]

The problem is not with Linux or ext4, the latter of which can support a file system of 1 Exabyte. So, the limitation seems to be with QNAP's management of it, which presents us with the online / expansion limit of anything beyond 16TB. The ext4 format does have a 16TB file size limitation, so maybe that is what is triggering their code limitation.

All that said, is there a way to expand beyond 16TB from command-line while preserving the existing data? Also, has QNAP officially commented on the issue and when / if they might have full functionality to expand beyond 16TB via the existing GUI tools?

[Q]

just a little note because some people just can't read (i don't mean you nnsqnap):

qnap DOES support volumes >16 tb, absolutely no problem! everything's fine as marketed. you can create for example 8 x 3 tb to get 21tb usable space in a raid5. or 33 tb in the 12 bay nas.

the limitation is just the expansion of existing volumes without loosing data, which has been noted multiple times before (and by qnap on the website). if somebody does a new setup, it's completely irrelevant as no expansion is needed. and anytime you can delete the existing <16tb volume and create a new >16tb volume - of course then you need to backup the data first. but if somebody uses a +/- 16 tb storage device without doing a regular backup anyway (if it's not the backup already), i would really question that person's expertise.

All that said, is there a way to expand beyond 16TB from command-line while preserving the existing data?

i'm not sure, but so far i didn't stumble upon that possibility here in the forum (although i may have missed it of course, let us know if you find something). afaik the linux/ext4 file system tools just can't do it yet (if that's still correct?), so not a qnap-only problem.

Also, has QNAP officially commented on the issue and when / if they might have full functionality to expand beyond 16TB via the existing GUI tools?

didn't see any statement on this so far. guess it's difficult because it doesn't depend upon qnap only.

[Nemeas]

Bumping this thread. The latest release of e2fsprogs now supports migrating over 16TB raid on e.g. Fedora 17. Can we expect simular functionality in QNAP soon?

[MicF]

I'm kind of confused, too.

Read the note 11 before buying my QNAP, but just for certain drives.
So I checked the drive recommendation list and bought the Hitachi 4TB without the note11:

2012-06-16 12-04-41_QNAP - Products - Compatibility - 3.5_ HDD.png

So why can't I expand my RAID.
I've not be warned and explicitely checked all to information I should.

So if note11 is applicable for all drives, it should be mentioned somewhere.

BTW Backup
I agree a Backup should be made, if the data is important.
But it's a pain in the **, to copy it back from an incremental backup.
Especially if it's not at home but somewhere in a bank's safe.

[P3R]

So if note11 is applicable for all drives, it should be mentioned somewhere.

Unfortunately the list is presently incorrect. With the new 16-bay models, all disks down to 1.5 TB should have the note 11. Or even better, as it isn't really tied to specific disk models, the limitation should be clearly announced in some other way.

The limitation is that RAID-volumes can't be expanded beyond the 16 TB limit of usable storage.

[LeoLeandro]

Hello Guys.

any news about that?

It is in the plans of Qnap to update the Expander to be able to upgrade in a volume more than 16TB?

I'm actually running 7 3TB hard drives in my Qnap TS-859Pro+ and are waiting for an update to be able to expend to my 8th drive.

[TomasF]

The feedback I got from tech support last week is that the goal is to get this into FW 3.7.3, but that it will require a reinitialization (reformat) of the raid to be able to expand beyond 16TB. But then again I was told the same by presales only that it would be in 3.6.3, which became 3.7.x. So when that was out I bought the TS-1079 Pro only to find it still wasn't fixed. So here I am sitting with a fancy new NAS and 5x4TB disks that there's no point in putting in production... :-/

[MicF]

Reinitialization would be really bad.

I got 6 x 4TB and 2 for future expansion.

[delos]

Hi,

I have a QNAP 859 PRO with 8 bays. Up to know I am using 3 single 1.5TB drives each as a single volume. Now I want to upgrade to 8*3TB RAID 5. I understood that I cannot first insert five 3TB drives create a RAID 5 volume, copy the content of the other three single volumes to it and then expand to 8*TB. Can I remove the three single volumes, create a 8*TB volume and copy the content of each removed 1.5TB disk to the new large volume? In other words, can the old drives be inserted into an external USB case and then attached to the QNAP? Since each drive is one single volume it should be possible, right?

Best regards,
delos

BTW: since I am knew here, I would like to say hello to everyone

[pwilson]

So if note11 is applicable for all drives, it should be mentioned somewhere.

Unfortunately the list is presently incorrect. With the new 16-bay models, all disks down to 1.5 TB should have the note 11. Or even better, as it isn't really tied to specific disk models, the limitation should be clearly announced in some other way.

The limitation is that RAID-volumes can't be expanded beyond the 16 TB limit of usable storage.

Unfortunately you are absolutely correct. I did a string search in the QNAP Turbo NAS User Manual for "16TB" and the only reference returned was in the "Virtual Disk" section:

The maximum size of a virtual disk the NAS supports is 16TB.

There is absolutely no reference in the QNAP Turbo NAS User Manual for this RAID expansion limitation. We could complain if we wanted, but I believe the upcoming Firmware 3.7.2 scheduled for release by the end of this month, is allegedly supposed to address this issue.

Patrick

[schumaku]

The "note" scheme to indicate this limitation is clueless - and does lead to more confusion. A simple text statement would make things much clearer IMHO.

[TomasF]

I agree with the recent posts on the problem with this poorly worded and obscure note to describe a serious limitation in core functionality that affect the models that represent the really big investments. What makes it even worse is the poor communication on when it will be resolved. I was told by presales it would be fixed in 3.6.3, which became 3.7. Obviously it wasn't. Now tech support is telling me it'll be in 3.7.3, while Patrick Wilson obviously has a reason to believe it would be in 3.7.2... I'm downloading 3.7.2 now, so I guess we'll just have to try ourselves

[P3R]

Unfortunately the list is presently incorrect. With the new 16-bay models, all disks down to 1.5 TB should have the note 11.

I did report this and several other errors in the compatibility list to a Qnap employee a while back. They did correct one thing (Seagate ST3000VX000 incorrectly categorized as an enterprise disk) but the things I have found so far still remaining (maybe the web guy is on vacation?) are:

• Since the introduction of 16-bay models in the TS-X79-line, all disks down to 1.5 TB capacity should carry the Note 11 remark for those models. Even better would be to rethink the whole way the list is designed (why didn't they in the big web site redesign?) but if this is changed, at least the list wouldn't be incorrect.
• Note 12 is incorrectly referring to only 3 TB disks.
• Seagate ST3000VX000 and the WD WD30EFRX (as all other 3 TB or larger disks) should have (at least) notes 11 and 12.

The list, in it's current design, have grown to a monster the guys updating the list obviously have problems maintaining.