Maximum drive size for Terastation 3400

[Kane88]

Does anyone know what the maximum drive size is for the Terastation 3400 series?

According to this post, supposedly there is no 16TB size limit for Terastations.
http://forums.buffalotech.com/index.php?topic=24730.0

And I'm not able to find any other info on this.

Recently, I was not able to get four 8TB disks working for 32TB total space on the TS3400 series.

With the 3400, the array build fails.  The LED display goes read and it shows raid build failed.
The array can be formatted in the console, the led screen will go back to normal functions, but the disks cannot be checked afterward.
Also: the array can be deleted, but a new one cannot be created.

The TS3400 does work just fine with 4TB disks.

The 8TB drives work just fine in a 5400 series unit.  But this does not solve the question for the 3400 series.

I contacted support and was given the response- that the 3400 series was shipped with 16TB drives.

Thanks.

[1000001101000]

TS5400 is a 64-bit intel based device
TS3400 is a 32-bit armv7 device.

The 16TB volume limit would apply to the 3400, though 2x 16TB volumes should work.

[1000001101000]

Actually, thinking about it.. this device has a CPU which supports lpae which i would have thought would avoid that limit. I don’t know if Buffalo’s kernel uses lpae but my debian installer will install the lpae version of the debian kernel. You could try that and see if that solves the problem.

[Kane88]

TS5400 is a 64-bit intel based device
TS3400 is a 32-bit armv7 device.

The 16TB volume limit would apply to the 3400, though 2x 16TB volumes should work.

That makes sense.  I will try that later when I have some more drives.

Actually, thinking about it.. this device has a CPU which supports lpae which i would have thought would avoid that limit. I don’t know if Buffalo’s kernel uses lpae but my debian installer will install the lpae version of the debian kernel. You could try that and see if that solves the problem.

I'll try out the debian at some point.
I'm still in the process of upgrading some storage, which will free up some stuff for testing.  Once that is done, then on to getting some sort of test rig going for Debian.

Maybe we need a general Debian thread.
I'm starting to think going that route might be a good thing w/these older units for many reasons, if not at least in regards to keeping up with latest SMB and security stuff.

Is it possible to construct some sort of custom TFTP boot, to where the non-intel buffalo devices could boot TFTP, and then run the debian installer via the usb flash drive- as the intel units do?  That might make things easier.  Honestly, I'm lost on the whole wget thing in trying to get one of these TS-XEs going.  I have to take some more time on that...

I have some XEs that have no caddies.   I found some long head screws to where I can finally physically mount some drives and start getting a TS-XE test box going...  the drives actually slid right in, I was surprised.

Anyone have a 3d printer?

[1000001101000]

Is it possible to construct some sort of custom TFTP boot, to where the non-intel buffalo devices could boot TFTP, and then run the debian installer via the usb flash drive- as the intel units do?  That might make things easier.  Honestly, I'm lost on the whole wget thing in trying to get one of these TS-XEs going.  I have to take some more time on that...

The installer is contained in the custom uImage.buffalo and initrd.buffalo files. You could boot from them via TFTP if you prefer, no need for any usb media. Since the TFTP ip address is not (easily) changeable, changing your network to 192.168.11.* is a hassle, and initiating TFTP boot varies from device to device I've never bothered with it.

Maybe we need a general Debian thread.
I'm starting to think going that route might be a good thing w/these older units for many reasons, if not at least in regards to keeping up with latest SMB and security stuff.

That would be great. Some howto's for the wiki would also be great.

I have some XEs that have no caddies.   I found some long head screws to where I can finally physically mount some drives and start getting a TS-XE test box going...  the drives actually slid right in, I was surprised.

It's probably a bad idea to do that long term, but I did find once that some standard case screws made a perfect spacer for drives in an LS-QVL.

[Kane88]

Is it possible to construct some sort of custom TFTP boot, to where the non-intel buffalo devices could boot TFTP, and then run the debian installer via the usb flash drive- as the intel units do?  That might make things easier.  Honestly, I'm lost on the whole wget thing in trying to get one of these TS-XEs going.  I have to take some more time on that...

The installer is contained in the custom uImage.buffalo and initrd.buffalo files. You could boot from them via TFTP if you prefer, no need for any usb media. Since the TFTP ip address is not (easily) changeable, changing your network to 192.168.11.* is a hassle, and initiating TFTP boot varies from device to device I've never bothered with it.

It sounds like all I would need to do is just copy the boot files into a known working TFTP setup?
If so, I will try that when I have some time. 


While I agree the 192.168.11.x IP is a hassle, Buffalo TFTP can be done fairly easily with two computers.
Just put the NAS, and the two PCs on the same switch.  I just use my regular home router's ports.

Set PC1 to be 192.168.11.1 and run the TFTP server on this one - I use my HTPC
Leave PC2 on DHCP - run the firmware updater app with this one-  I use my main desktop PC.
I've done just about all my TFTP firmwares this way, no problem.  Very straightforward.
If anything, getting the right boot files extracted are the problem moreso, than getting the network IPs up correctly.

After the nas boots on 192.168.11.x, the buffalo firmware switches to DHCP, and can the unit can be found on the regular local subnet.

Now I don't know if your custom installer will do that switch, but I have noticed just about all buffalo terastations and linkstation TFTP boots will do this.

I have to read up on the wget stuff.  I really am getting lost with that.  My command line is not very good.  I watched the video on your wiki, the guy goes so fast- I was still lost afterward.

--

I have some XEs that have no caddies.   I found some long head screws to where I can finally physically mount some drives and start getting a TS-XE test box going...  the drives actually slid right in, I was surprised.

It's probably a bad idea to do that long term, but I did find once that some standard case screws made a perfect spacer for drives in an LS-QVL.

True- I figured as much, probably too much vibration which is not good for the drives.  And of course- the drives don't lock in either.
Just wanted to try a quick test.  They're pretty close, at least the sata connector on the backplane isn't bending...

What kind of standard case screws did you use?  The long head screws I tried- are the hex head ones with the thicker thread for Hard Drives, pci/vga slot covers, and some motherboards.


--

Other question:
Is it possible to switch for example the LS220DE bios firmware into one of the other LS220 units?  (the DE boots to EM mode automatically, the other D series units do not).  It seems there should be a way to convert the bios firmware to the DE version somehow...

[1000001101000]

It sounds like all I would need to do is just copy the boot files into a known working TFTP setup?
If so, I will try that when I have some time. 

Exactly.

All boot methods are basically just a way to load the kernel(uImage.buffalo) and initrd (initrd.buffalo) into memory and then execute them.

After the nas boots on 192.168.11.x, the buffalo firmware switches to DHCP, and can the unit can be found on the regular local subnet.

Now I don't know if your custom installer will do that switch, but I have noticed just about all buffalo terastations and linkstation TFTP boots will do this.

The debian installer will also set an address via dhcp.

I have to read up on the wget stuff.  I really am getting lost with that.  My command line is not very good.  I watched the video on your wiki, the guy goes so fast- I was still lost afterward.

should be pretty straightforward if you have python installed, though if your on Windows you may need to install it first. Otherwise post your console output and we’ll take a look.

I think the screws I used were hex-head case screws with the correct thread (just what I had around). Probably not a great idea for the reasons you mentioned though it worked surprisingly well.

My installer example assumes you’ve got a device with working firmware, whether it has nand or not doesn’t make a difference at that point.

[Kane88]

It sounds like all I would need to do is just copy the boot files into a known working TFTP setup?
If so, I will try that when I have some time. 

Exactly.

All boot methods are basically just a way to load the kernel(uImage.buffalo) and initrd (initrd.buffalo) into memory and then execute them.

Ok, maybe I can get that going later when I have some time. 
 

I have to read up on the wget stuff.  I really am getting lost with that.  My command line is not very good.  I watched the video on your wiki, the guy goes so fast- I was still lost afterward.

should be pretty straightforward if you have python installed, though if your on Windows you may need to install it first. Otherwise post your console output and we’ll take a look.

I think the screws I used were hex-head case screws with the correct thread (just what I had around). Probably not a great idea for the reasons you mentioned though it worked surprisingly well.

My installer example assumes you’ve got a device with working firmware, whether it has nand or not doesn’t make a difference at that point.

I have no idea how to install python on windows.  I downloaded an FTP app for windows, hoping there's a way to just navigate to wherever the boot files need to be copied to so the nas can boot.

Another thing is that I'm still having problems with java, to where it will not run unless the command prompt is on the java directory itself.

I have the java directory in my path statement.  Even after a reboot- it won't run unless I manually go to the directory java is in.  very strange.

[1000001101000]

Python.org provides a windows installer, it should be simple to install.

I'm surprised the java installer wouldn't have handled the PATH setup for you. At least you've got a workaround for that part.

[Kane88]

Python.org provides a windows installer, it should be simple to install.

I'm surprised the java installer wouldn't have handled the PATH setup for you. At least you've got a workaround for that part.

Python.org provides a windows installer, it should be simple to install.

I'm surprised the java installer wouldn't have handled the PATH setup for you. At least you've got a workaround for that part.

Yes for whatever reason, the java installer doesn't handle things, although it is in the path, it is really wierd.

I am getting ready to try working on a 3000 series unit again soon...
I'm going to do it on one that has the latest stock firmware clean installed, and attempt to test the LPAE (using 4x6tb disks for 24tb) if I can get the debian loaded and running...

I'm really stuck with this loading installer files part.

'Copy the installer files from your PC using sftp or wget. You could also copy them to a network share on the device, then copy them to /boot from /mnt/disk.... or /mnt/array....'

I haven't installed python yet.  Is that going to be needed for these commands?
Are the commands from this page to be entered in windows?
I'm confused as to how they are getting from an $ prompt... 
https://github.com/1000001101000/Debian_on_Buffalo/wiki/Example:-Loading-installer-files-using-stock-firmware

thanks

[1000001101000]

The commands in the example were run from my PC running debian. They only use java and python which should allow them to work form any OS that has them installed.

If you're having trouble doing this from windows you could try from one of the devices you've already installed Debian on. Python is part of the default installation and java can be installed as simply as:

sudo apt-get install default-jdk

[Kane88]

Just an update on this for those interested- before the Debian install.
After I loaded the stock firmware 1.92 onto the 24TB array (4x 6TB disks) in the TS3400:

The system boots.
The RAID 0 default format for 24TB failed just like with the 32TB array.  So 16TB is definitely the limit with Buffalo's stock os.

I made one 12TB RAID 0 array.  And it worked ok to create a second 12TB RAID 0 array.  Checking both arrays worked fine (checking and formatting both fail on arrays larger than 16TB).  I want to say I could not make two separate 16TB arrays when I tried the 8TB drives awhile back, but I don't recall.  The 12s certainly work.

I mapped both RAID 0 arrays and wrote some data on both- but I did not fill them entirely.  Both wrote at reasonable speeds for this model, although I have seen this unit be faster too.  For all intents and purposes- these 12TB arrays are probably fine.  I'd go with this setup, but the idea is to use less windows drive letters and max size of course...

I did try making a RAID 10 array.  That one worked to the point of where it wants it to sync all 24tb.  I did not let it finish the sync, it wants over 3000 minutes to do it!

Anyway, onto installing Debian 10.3

[Kane88]

The commands in the example were run from my PC running debian. They only use java and python which should allow them to work form any OS that has them installed.

If you're having trouble doing this from windows you could try from one of the devices you've already installed Debian on. Python is part of the default installation and java can be installed as simply as:

sudo apt-get install default-jdk

Ok, got it.  I'll be using the TS-WVHL to run the commands from the guide here:
https://github.com/1000001101000/Debian_on_Buffalo/wiki/Example:-Loading-installer-files-using-stock-firmware

I am assuming the installer will throw some sort of error(s) if LPAE doesn't do what is needed to make one RAID 0 24TB array.  We'll see what it does.

[1000001101000]

it's been a while since I tried to make a volume > 16TB on any system. One thing that I remember was a lack of errors when creating/mounting volumes. The errors would mainly manifest when trying to write to blocks past 16TB.

For ext4 there is an option that must be set to allow > 16TB volumes to be created I don't recall what it is but I believe it became the default in the past few years.

I don't think I had to do anything special to create >16tb XFS volumes.

[Kane88]

Ok, thanks.  That helps.  Hopefully I can get that far.

In your example, I take it that 192.168.1.131 is the Buffalo device to install Debian on.
and 192.168.1.146:8000...  that would be your linux pc (or in my case, the TS-WVHL).

--

I already have a question before I get started about the root login info...

EDIT:  I think I just answered it:
Use acp_commander to enable a root shell over telnet

java -jar acp_commander.jar -t <device ip address> -pw <your admin password> -o

Connect to the device via telnet, the username is "root" and the password is blank (just press enter).
--