Having Issues with my NAS. Shares missing, WebUI broken.

[Jocko]

So the backup file has been created :thumbup
Now all you have to do is wait for the reshaping to be completed

[Woodani]

Ok. I will let it run and post here if I have any issues otherwise I'll let you know when it finishes.

Thanks.

[andjohn]

Hey Jocko and FVDW,
Is it possible to have the system partition 'synced' from SDA to the other drives as they are initialized and then keep them 'up to date' with a type of rsync? What I'm trying to explain is it'd be super useful to have the system partition on all disks with the settings saved and synced across them so that you will always have a working copy. I think this is the only downside to this firmware, as lacie's garbage firmware does have this feature. Like you said in this post though, the data is all good still, it's just that the recovery would be a lot faster. You would simply add a new disk into SDA and on boot up, it would find the next system partition in SDB or whatever.

However, I bet you guys have already looked into this and it's not as easy as I'm typing. Thanks for being awesome to older hardware long after Lacie abandoned it!

[andjohn]

Or even a small recovery partition that would be used to say 'hey, do this to get your stuff back' in a web server or something.

[fvdw]

Hi andjohn

Good idea but there are some considerations why we did not do that and choose another way for recovery.
To explain some background:
For the fvdw-sl firmware the system must run from disk sda and sda is the disk in the first slot on lefthand side seen from back of the 5big2.
The bootloader (uboot) of the lacie devices load the kernel from disk sda and passes the file system on partition 7 of sda as root file system to the kernel. You cannot change that because it is hard coded in the uboot image, uboot is in flash memory. Why lacie decided to do that I don't know, but if you want to change that you need to compile a new uboot version and flash it to flash memory which is not without risk of bricking the nas if it fails
When sda fails there is no way to boot the nas even if you have a copy of kernel and firmware on another disk as uboot fials to load a kernel or root file system.
For that reason we developed the fvdw-sl console and a standalone kernel to be able to boot the nas even without a disk (the standalone kernel runs from ram). With the standalone kernel we can investigate whats wrong and repair it.
The fvdw-sl console has options to write a firmware image to sda7, sda1 and sda2. That could be used for recovery. The console can also be used to swap active boot partition are install firmware on a new disk. Most of the time when a root file system fails there is a reason as for example bad blocks or other disk errors, writing a copy of the firmware to a partition with bad blocks is not a good idea.

But thanks for your suggestion we appreciate it.

[andjohn]

Hey no problem! I was thinking there was a problem with the idea, or you would have already done it, a hard mapped point to SDA. I have another idea that might not be feasible either but if you'll bear with me a moment.

1. System partitions on all disks with copies of the settings etc.
2. All mappings to disks are using uuid instead of SD* throughout the OS, so that on boot, the disks are found regardless of their position.
3. When disk 1 fails, then you could simply move one of the other disks into disk 1 location and boot again. Your RAID could repair if you added another disk as the raid would be looking for the uuid instead of absolute position.
4. Success?

I don't know if there's any issues with this solution, as I'm simply someone who knows enough to ask annoying questions :P

I know that I have done this with a traditional linux install, swapped disks around with no problem because fstab has the uuid instead of SDB etc. (I had a JBOD card crap out and had to move my disks around).

[fvdw]

yes using disk uuid would be better, unfortunate the bootloader does not use it. At least no the one on the 5big2.
The solution for that could be implementing a initramfs in the kernel and use switch root command. But still the current firmware still needs sda as system disk. We are planning to change it to be able to run firmware from any disk in a multiple disk nas.

[andjohn]

Very cool. I wish you luck! Also, I notice that someone else mentioned they'd like to contribute on github or something. It might be a push that the project needs? Anyways, thanks for your answers to my questions. Have a good day!

[Woodani]

Just an update on my NAS. I'm currently 50% done reshaping my chunk size with still over a week left.

Code: Select all

root@fvdwsl-base:/ # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md0 : active raid5 sda8[0] sde8[4] sdd8[3] sdc8[2] sdb8[1]
      15616464896 blocks super 1.0 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]
      [==========>..........]  reshape = 50.0% (1955355648/3904116224) finish=10269.0min speed=3162K/sec

unused devices: <none>

[Jocko]

Hi

Thank you for the feedback. I know reshaping is a process requiring a lot of resource and with 5big2 cpu the sync speed is slow. But I would expected a bit faster... (in your case I expected 5-7 days)

So can you post these output

Code: Select all

cat /proc/sys/dev/raid/speed_limit_max
cat /sys/class/block/md0/md/sync_speed_max

Currently please do not change this value or never set a max speed upper than 15000-20000. Otherwise your nas may be hanged

Note: You may get also this slow speed if another processes are running such a media server (twonky, minidlna,...) or a p2p server (mldonkey, transmission,...). So it may be better to stop them during the raid reshaping