Maximum drive size for Terastation 3400

[1000001101000]

Two dashes for each.

Looks like it should have been “seek” not “skip”

[Kane88]

seek worked this time

thanks

[1000001101000]

Are you able to confirm you can write to 20tb but not 30tb? If so that is a pretty neat outcome.

[Kane88]

I stopped after this

root@debian:~# dd if=/dev/zero of=/dev/md10 bs=1G seek=22000 count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 45.6849 s, 23.5 MB/s

root@debian:~# dd if=/dev/zero of=/dev/md10 bs=1G seek=23000 count=1
dd: /dev/md10: cannot seek: Invalid argument
0+0 records in
0+0 records out
0 bytes copied, 0.00804384 s, 0.0 kB/s

I formatted the partition.  It seems to be working, which is pretty cool.  The stock firmware writes a good 2x to 3x faster though.  These drives run at worst 100MB/sec on a windows machine.  They're not slow disks...  I guess buffalo uses something to optimize their os.  Is there some kind of write caching or something else that needs to be added to the install?

[1000001101000]

Is this raid zero or linear?

Either way that dd command was horribly inefficient, I used 1g as the block size to make the math easy but in practice it would destroy your performance.

A safe/quick test to show more real performance would be:

Code: [Select]

dd if=/dev/md10 of=/dev/null bs=4k count=10240

[Kane88]

I used the default partitioning config the buffalo firmware tried to make, which is raid 0.
I left the large partition alone during the debian install. 
The installer was showing it as raid 0, and it wasn't formatted.

How do I check if raid 0 or linear? 

Given the root acct recovery problems I was having with the TS-WVHL, I'm in the process of blowing out the debian install on the TS3400 and starting over with root enabled.

I will try your new test when it's done.

[1000001101000]

Note that the recovery option we're talking about doesn't help without a physical terminal to connect to.

If you didn't go out of your way to make it linear nothing would have done it for you. I'm a bit surprised it defaulted to raid0 but would make sense.

"mdadm --detail /dev/md10" tells you everything about the array including raid level.

[Kane88]

The TS3400 firmware installer defaults to RAID 0 for the user data array.

Well in that case, there's no need to enable the root acct then since the TS3400 and the TS-XEL don't have video ports.

I'm reinstalling one more time, with the root disabled.  There wasn't even a way to reboot the terastation.  I was running into some big difficulties...


root@debian:/# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

kane88@debian:~$ shutdown -r now
-bash: shutdown: command not found
kane88@debian:~$ cd /
kane88@debian:/$ shutdown -r now
-bash: shutdown: command not found
kane88@debian:/$ sudo su -
[sudo] password for kane88:
kane88 is not in the sudoers file.  This incident will be reported.
kane88@debian:/$ su
Password:
root@debian:/# shutdown -r now
bash: shutdown: command not found
root@debian:/#



I couldn't do this
kane88@debian:~$ sudo su -
[sudo] password for kane88:
kane88 is not in the sudoers file.  This incident will be reported.
kane88@debian:~$

I could do this
kane88@debian:~$ su
Password:
root@debian:/home/kane88#

I couldn't do this
root@debian:/home/kane88# dpkg --install webmin_1.941.all.deb
dpkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
root@debian:/home/kane88#


None of these problems were happening w/root disabled.

[1000001101000]

If you use “su -“ instead of “su” most of those problems will go away.

[Kane88]

Ok, so the TS3400 is reloaded with root disabled:

ran tests
root@debian:~# dd if=/dev/zero of=/dev/md10 bs=1G seek=22000 count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 58.6727 s, 18.3 MB/s

root@debian:~# dd if=/dev/md10 of=/dev/null bs=4k count=10240
10240+0 records in
10240+0 records out
41943040 bytes (42 MB, 40 MiB) copied, 0.298845 s, 140 MB/s
root@debian:~#

and now having some problems problems formatting the array

root@debian:~# mkfs.ext4 /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: dfb8c4e4-3aba-4bfb-93e5-82c9a22e371d
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

root@debian:~# mkdir /mnt/array

root@debian:~# mount /dev/md10 /mnt/array
mount: /mnt/array: wrong fs type, bad option, bad superblock on /dev/md10, missing codepage or helper program, or other error.

root@debian:~# uname -a
Linux debian 4.19.0-8-armmp-lpae #1 SMP Debian 4.19.98-1 (2020-01-26) armv7l GNU/Linux

root@debian:~# mdadm --detail --scan
ARRAY /dev/md0 metadata=0.90 UUID=520ff40a:771a4a9a:e97df895:e01ccbc7
ARRAY /dev/md/1 metadata=1.2 name=TS3400D-EMAEA:1 UUID=bc2a312c:9e69a15e:e2c23f68:356e26a7
ARRAY /dev/md/2 metadata=1.2 name=TS3400D-EMAEA:2 UUID=8fed1747:dedae5ac:02cdf5ff:0606eba5
ARRAY /dev/md/10 metadata=1.2 name=TS3400D-EMAEA:10 UUID=998beb61:15e2396c:306eea0a:54ff59c9
root@debian:~#

[1000001101000]

I’m not super familiar with xfs options. There must be an option required to create it as > 16tb (>32bit). We’ve already established ext4 will work with the current defaults, otherwise you can research xfs options.

[Kane88]

Last time, it formatted just like it did yesterday.  The mkfs.ext4 /dev/md10 has worked both times.
Though I am not sure it has ever mounted correctly to begin with.  I have never been able to write any file data to it.

I found this article, but the commands don't work when I enter them with /dev/mapper/md10 and so on.
https://askubuntu.com/questions/779754/how-do-i-resize-an-ext4-partition-beyond-the-16tb-limit

It mentions enabling 64 bit support.  The TS3400 doesn't have a 64bit cpu, so I don't see how that will work, unless it is just for the file system.

I'm out of ideas.  It seems like OS support for this is currently spotty at best.  Maybe it is best for now to drop back to using 2x 12tb raid 0 arrays with the stock os for now.  And revisit this later when OS support for it is better.

[1000001101000]

if mkfs.ext4 didn't throw an error the fs was presumably created without issue. There would be no need to re-size it after the fact.

what actually happened when you tried to mount it?

[1000001101000]

This might help you with setting up your fstab:
https://help.ubuntu.com/community/Fstab

[Kane88]

if mkfs.ext4 didn't throw an error the fs was presumably created without issue. There would be no need to re-size it after the fact.

root@debian:~# mkfs.ext4 /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: dfb8c4e4-3aba-4bfb-93e5-82c9a22e371d
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

what actually happened when you tried to mount it?

root@debian:~# mkdir /mnt/array

root@debian:~# mount /dev/md10 /mnt/array
mount: /mnt/array: wrong fs type, bad option, bad superblock on /dev/md10, missing codepage or helper program, or other error