Ts410 Sap

[Ahmend Studioz]

Soi just inherited a TS410 from my late mother, she had the very unsave old QTS running, didnt do any updates, but since she died as one of the frist covid victims back in 2020 , that unit did get spared the big QNAP hack. It was simply offline , Im being gratefull for the little things here.

Now I dont want to have any QTS running what so ever , I have had only bad experience with those limited OS stuff. Googeling found me this guy describing how to get debian on these ARM platfroms used by similar machines...

Im currently getting buster installed, what i can tell you guys already is this, its slow, and just for fun I will try omv5 on it, see how it runs, and then likely Im going ahead for bullseye and omv6

kirkwood = armel. omv-extras hasn't supported armel since the early OMV 3.x days. Can it be made to work for something? Sure but as you said it is going to be painfully slow. You would better off to find an RPi (even an RPi2 would be better).

and hopefully it still handles aobut 15Mb/s of SMB trafic, at least thats what the QTS got out, i did just move Tbs of data with that speed, but mostly slower with lots of small files 1Mb/s and such, took days... I for sure will pack up my gravejard data into bigger rar files... faster transfer and smaller footprint, win-win.

You got a point with the Pi, but the thing about the pi is, the TS410 has a nice housign, supports 4x 3,5" discs out of the box and such simple things the pi has not. I got it for free, the pi and accessories I would need to spend money on a data grave thats almost as slow, na... no way.

I get it. I just worry when people start using something that old even if they aren't that worried about it. If you can get Debian 11 on it, you can install OMV 6.x with this guide - Install OMV6 on Debian 11 (Bullseye). After that, no need to install omv-extras since there is no armel repo.

so setting up raid 5 on the machine. syncing the drives at inital setup an at the same time formating them with ext4 kills the unit basically, the web ui drops out once in a while, but considering the sys load, its still very responsive.

With a mergerfs pool, only the data on the missing disk would be gone. Snapraid could solve that. It isn't realtime which would be better for that slow cpu. Raid is about availability and your qnap can't possible need to be always available lol at its age (nothing HA about it either).

right now i just want to have the raid5 going for one reason only. That was what the QTS OS offered, and I want some comparison for speed between the QNAP neutered version of bussybox for their hardware and a kind of much newer stock debian on the very same hardware and with a rather similar config.

of course, especially thanks to your recommendations, when it goes into "production" as a data grave, i will switch over to mergerfs and snapraid, never did that before in combination, but well, im here to learn. just need to figure out how to prevent it from shutting down when i tell it to, if the snapraid is not finished syncing. maybe have a once a week start up on schedule to check for snapraid for in sync, and if not, do a sync, otherwise shut down again. something along those lines

i probably will have a structure in my normal file storage for "data grave" and once a week the old ts410 goes online, sucks that up by moving it through SSH, then do a snapraid resync and shut down again.

for ease of doing it i did go with everything in one place this time, but i do understand why / home var temp usr etc and so on goes each to different partitions, its basically to make the system more safe and stable, like users not being able to fill up the root fs, share usr with other OS or even make it ro, chose a fast file system for temp but a reliable one for home... most of the stuff does not apply to my use with OMV on top. data does go to the data partition only anyway and the rest is basically the OMV and its updates... and if I need to update form CLI i usually go su - to spare me typing 23,583 times sudo and with OMV one goes to the cli as root anyway.

yes, sir, nicely put, sir, I already regret going that way, sir. indeed i do, at least a very little bit. how ever I always like testing some stuff out. no harm no foul, and there still is the option of just ditching the thing.

ill wait an other bunch of days (forcast says 3-4) just to get my comparison data. guess it will be a bit faster after the sync load is gone. having an average load of 10 on a single core unit just tells the storry. (with the smb file transfer the load went to 43 )

i may go back to a bare metal debian and run from cli, but probably i just suffer through the first setup and then never go back to the box. let its do its job as a data grave and while its online just pull stats off it to monitor the discs just in case.

the final transfer rates where not that bad, actually they where a bit (marginally) better than what I did see with the QTS firmware, so i went ahead to move to bullseye, and somehow screwed it up. totally.

I suspect I should have removed the OMV5 prior to the full-upgrade, as its not a debian packet. I also somehow managed to get my admin password changed to something I did not know. and first-aid did not work, but dont recall why.

funny thing is, I had to set the interface mac address after returning to QTS, but it only stuck on one interface during the ove to debian, as both where 00:00:00:00:80 and :81 in the beginning, flash debian was not willing to pull my manually set mac, so i had to comment the 05:09 part out from the script and now I have eth1 with its original mac and eth0 with 00:00:00:05:09 as mac....

since I could not get mergerfs during the install, i went ahead and made a raid0 for swap with 4 times 250mb and a raid5 over 4 discs with the rest, then had debian do a fully and all mountpoints seperated partition setup on the raid5, but changed that to kill the swap partition as I had that on the raid0 and then to move tmp up to fill the swap hole and downsize home to 5GB. now i got almost 9TB on the raid5 to be ready for OMV, but I also have my OS and stuff on the raid, not like with QTS, where the OS is only on the master (1st) disc and when that one fails, the whole unit is half dead. (had that one experience, well I could recovere the data, but it was a PITA)

i did try that at first, and it failed, IIRC it had something to do with the building before flashing of the latest buster kernel. I already had some issues flashing the OMV kernel onto the debian buster kernel on my marvel kirkwood trash can

but i figured that since my userer case is a bit spacial and i suspect more than just rare, i wont need to anoy any of the omv maintainers with it, did try the debian ugrade procedure and killed my system enought to go back to the QTS recovery

3a8082e126