15.1 and External USB disk docking station

[mdi]

Hi Jocko,
I tried to connect only 1 disk with a Sata2USB cable. The disk was mounted. So I run one of the backup scripts and it started working, but then, suddenly I got this:

Code: Select all

...
mdi/Backup_Acer/D/Musica/MP3/Shineoma/Ventagli.MP3
mdi/Backup_Acer/D/Musica/MP3/Shineoma/Ventagli.doc
mdi/Backup_Acer/D/Musica/Registrazione/
mdi/Backup_Acer/D/Musica/Registrazione/Forever.bun
rrsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/share/1000/data1_1/mdi/Backup_Acer/D/Musica/Registrazione/Forever.bun": Read-only file system (30)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (69598 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]


And the disk is unmounted.

Code: Select all

e2fsck /dev/sdb1
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: No such file or directory while trying to open /dev/sdb1
Possibly non-existent device?


The cronjob.log:

Code: Select all

crond: USER root pid 9050 Rsync script started at : 08/03/2014 06:57:47 PM
crond: USER root pid 9050 USB share is available !
crond: USER root pid 9050 Rsync command successful !
crond: USER root pid 9050 Rsync script ended at : 08/03/2014 07:04:24 PM


Same story with the other disk (different file):

Code: Select all

...
mdi/Backup_Acer/C/Desktop/Documenti/Club Medusa/Club.LOG
mdi/Backup_Acer/C/Desktop/Documenti/Club Medusa/Club.cfg
mdi/Backup_Acer/C/Desktop/Documenti/Club Medusa/Club.mdb
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/share/1000/data2_1/mdi/Backup_Acer/C/Desktop/Documenti/Club Medusa/Club.mdb": Read-only file system (30)
rsync: connection unexpectedly closed (11469 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]


So, now I suspect that the disk has something strange, but why does it say that I have a ro filesystem, while it was actually writing since a while before?...
Do you think I should re-format?.

It seems that the disk goes in stand-by. Is there a way to check if the disk is set to go in standby on its own? Strange that it does while it is being used.... :tapfoot

Or maybe I can try formatting with MBR?... do you think I shall try?

Thank you,
MDI

[Jocko]

Hi mdi
I am not at home this we

You could rebuild fully the partition table of one disk and use first an ext3 fs. Later you can swap the fs to ext4. But first see if you have the same behavior with ext3...

[mdi]

Hi again,
I tried all possible ways:
- docking station with 2 disks connected;
- docking station with 1 disk connected (tried with both disks);
- sata cable for 1 disk (tried with both disks);
- using the PHP script;
- directly using rsync command, with --size-only and no -og options (like I was doing before with the network NTFS disk).

I always get the same problem (but in different moments of the backup, so different files).
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/share/1000/data1_1/mdi/Backup_Acer/D/Musica/Sound/Un Motivo HipHop no vocals.wav": Read-only file system (30)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (70896 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

I just notice that the data stop flowing to the external HDD, the docking station LED stops blinking.
Then I get disconnected from at least once SSH sessions (I have 3 opened, 1 for the rsync/script command, 1 to tail the cron.log, 1 to tail the mdi.log which is the actual rsync log).
Then I get the error in mdi.log.

So, I don't understand what happens. The external disk seems to become read-only, the disk is unmounted, rsync goes in error and at least 1 ssh sessions disconnects.

It seems to happen when there is a sudden continuous write, like in case of big files of >200Mb. But I'm not sure of this.

I see that with 15.1 the mounting mechanism is a bit different, using the rw_fs/tmp filesystem. Could this have any impact?

I'm not sure now that this has to deal with the HDDs.... their fs is reported as clean by e2fsck.
I don't think that write_unbuffered can cause problems (see rsync message above).

I'm stuck :(

[Jocko]

Hi mdi,

It's not a rsync issue but a file system problem. So change some rsync options has no consequence.

You get a readonly mount because at some times happen I/O errors. In this case, the disk is unmounted and mounted again but with the option ro.

It's why I would check if with a ext3 file system you have the same behavior.

[mdi]

Hi Jocko, sorry, I didn't read your post about your availability. I will try formatting to ext3 and let you know.

Thank you,
MDI

[mdi]

Unfortunately it didn't work. Same error even when the disks are formatted ext3.
It happens during the backup, but on different files, so it doesn't seem related to the data......
:sob

[Jocko]

Hi mdi,

I repeat is not an issue with your data or rsync but an issue between the kernel and your disk.

As now, it is a long the topic, I prefer make a summary.
After mounting your ext4 disks, your disks are unmounted and mounted readonly :

Code: Select all

[96132.076142] JBD2: Error -5 detected when updating journal superblock for sdb1-8.
[96132.105414] EXT4-fs error (device sdb1): __ext4_journal_start_sb:60: Detected aborted journal
[96132.123907] EXT4-fs (sdb1): Remounting filesystem read-only             (<= this is the normal behavior is that case)
[96132.131524] EXT4-fs (sdb1): previous I/O error to superblock detected
[96132.143971] EXT4-fs error (device sdb1) in ext4_da_write_end:2870: IO failure
[96132.151159] EXT4-fs (sdb1): previous I/O error to superblock detected
[96132.279673] EXT4-fs error (device sdb1): ext4_find_entry:1300: inode #83886082: comm rsync: reading directory lblock 0

This happened after Buffer I/O Errors. (do you still have this output in dmesg when you used rsync ?)

if your same disks are ext3 partitions, you got the same behavior.
So now I am pretty sure that the issue is your docking station because nobody never had this problem with ext3 disks.

To check that, could you plug directly one disk without using your docking station ?
and try to read/write some files on it.

I think that you already did it but what is your docking station ?

Note: seems that you have the same issue than https://bbs.archlinux.org/viewtopic.php?pid=1377011#p1377011

[mdi]

Hi Jocko,
same issue you mentioned in the link, yes.

Your summary is right, even if the disk are NOT reconnected as RO, they stay disconnected. So I have to manually unplug and re-plug the cable.

The docking station is a Inateck FDU3C-2 USB 3.0 2 bays.
It could be a kernel bug for USB 3 devices when big amounts of data are sent to USB. It seems so, but I already tried to directly connect each disk through a normal Sata-to-USB cable and it still failed.

This week I'm going to connect the docking station to a Raspberry Pi computer and try to backup over the network.
If it's a kernel unsolved bug, it should fail also in this way. If it works, it could be the kernel version of the NAS.

Anyway I will let you know the outcome of this test.

[Jocko]

Thank mdi,

You could also try to change a system value.

After mounting the disk, what is the value in /sys/block/sdb/queue/max_sectors_kb (or with sdc).
and try to change the value (check if the disk is always mounted) with these one:

Code: Select all

echo 120 > /sys/block/sdb/queue/max_sectors_kb

Try values : 120, 64, 32

[Jocko]

Hi mdi,

do you have some progress about your docking station ? and what happens with your Raspberry ?

A fvdw suggestion, do you have enable the Spin-down guard USB disks of the usb disk menu ? if yes, you can try to disable it.