Unable to mount USB drive after rebuilding the storage node

Node Operators troubleshooting
,
22

The problem could be another: you tried to mount the /dev/sda (/dev/sdb) instead of /dev/sda1 (/dev/sdb1)
So, when you will be on other device try to use a /dev/sda1 instead of /dev/sda to mount it.
by the way, in the /etc/fstab it is much better to mount disks by UUID.
You can see a UUID by this command:

blkid

Using format without journal is not a good option, as a automount.
In case of power failure you could lose all the disk without a journal.
The automount can mount to a different mountpoint, if a previous one would be occupied or unavailable for any reason.
This is especially dangerous if you doesn’t created a subfolder on the disk for data. In that case if disk would not mount, the storagenode will try to create an empty structure in your mountpoint (i.e. on your system disk instead of disk with data) and will store data there and will fail audits for missed data, which on the disk but in the different mountpoint. When you finally mount the disk to the right place, it will start failing audits for data in mountpoint.

So, better do not use an automount option, use the /etc/fstab instead. Mount your disk by UUID, not by the path.

1 Like
23

My question is why you have so many ram disks?

24

This is default for raspbian and armbian.

26

@murthydevarakonda Were you able to remount your disk? And are you certain it was created as ext4? Using ext4 without a journal is risky, especially if you don’t have some sort of battery backup. Since Storj runs a db and has a lot of disk IO, it is probably not wise to tempt fate by using journal less for a slight performance bump.

I’m assuming this is also an actual hdd/ssd and not a ‘thumbdrive’ as the IO will likely kill a thumb drive.

If you’re trying to eak out a bit more from a slow drive, you can experiment with changing the --pieces.write-buffer-size value (referenced from GitHub)

27

Thanks Alex. I will take your advice for ext4 journal. I’m still don’t know the reason why I not able to simply mount my existing ext disk to my new armbian device. This is the reason I’m syncing data to a new disk and hopefully, it can be mounted there. After this, I will change to another disk with journal enabled.

I did a simple test yesterday, rsync with ext4 (no journal) and auto-insert mount on Pi3, that disk is able to be mounted on my new armbian device.

Rsyncing now, seems will take ages on USB2.0 :joy:

28

Especially on raspi3 - it uses a one USB channel for everything.
If you have a possibility, I would like to suggest you to connect both your drives to the new arm device and try it there.
By the way what is arm device is it? Perhaps it could work faster.
Maybe even more wise just format the new disk on that arm device and run your second node there.
You will have a two nodes, old on raspi3, and new one on that arm.

29

As Alexey already wrote, you tried to mount /dev/sda instead of /dev/sda1.

30

Finally, data has been migrated.

I was using Pi3 for almost a year. I got a small box equipped with Amlogic S805 chip a month ago. This tiny box is so cheap from reselling market, it is about US$ 6. So I flash Armbian to that box in order to release my Pi3 for other purposes. This is the pictures for that tiny box: OneCloud

Unfortunately, I noticed the existing ext4 filesystem from Pi3 is not able to be mounted on that Armbian, the error log narrows down to “EXT4-fs (sda): error loading journal”. I still don’t know the root cause, it might be a BUG in that Armbian image.

This is the reason I have to use ext4 without journal as a temp solution. I sync it one more time to a normal ext4 which is created on my Armbian with journal.

Anyway, everything is settled after almost 10 days of data sync.

1 Like