FreeBSD reboots when starting rsync to USB3 drive

B

bsus

Hi,

I have a WD Elements USB-3.0 which should work as backup drive using rsync:

This is the script:
Code: 
kldload /usr/local/modules/fuse.ko
kldload xhci
ntfs-3g /dev/label/extbp /mnt && rsync -av /home/user /mnt
umount /mnt

Rsync is sending an incremental file list and after the first three files freebsd FreeBSD breaks down and reboots.

How do I start debug?

Where could the issue be (in the xhci module?)?

Best regards,
bsus
 
Rsync causes kernel panic

Hi,

I am using rsync to backup incremental data from the zfs storage to a USB drive. Now I updated last week to FreeBSD 9 and since this upgrade rsync always causes a kernel panic. Is this a known issue? Which steps should I go to debug?
 
Have you recompiled the sysutils/fusefs-kmod port after the upgrade to FreeBSD 9?
Click to expand...
Yes, I recompiled all ports. I tried the USB drive at a USB-2.0 (without XHCI) and with USB-3.0 (with XHCI); both situations cause the same behaviour. So I think it is not directly the USB, more the rsync itself. Is this realistic?
 
As a test, play around with the --bw-limit option to rsync. Connect via USB2. Limit it to 1 MBps and see if it crashes. If it's stable, then increase to 10 Mbps. Then 50 MBps (about the practical limit for USB2).

If that works, then connect it via USB3, and repeat the tests, going up to 100 MBps.

It might be that you're trying to push too much data through USB.
 
I'd format that USB drive to UFS and restart the procedure. The murkiest component here is NTFS-3G's write stuff.
 
As a test, play around with the --bw-limit option to rsync. Connect via USB2. Limit it to 1 MBps and see if it crashes. If it's stable, then increase to 10 Mbps. Then 50 MBps (about the practical limit for USB2).

If that works, then connect it via USB3, and repeat the tests, going up to 100 MBps.

It might be that you're trying to push too much data through USB.
Click to expand...
Why doesn't FreeBSD catch such errors?

I will try this and give a response later on.


I'd format that USB drive to UFS and restart the procedure. The murkiest component here is NTFS-3G's write stuff.
Click to expand...
Will try this too ;)
 
bsus said:
Why doesn't FreeBSD catch such errors?
Click to expand...

It does. If --bw-limit fixes things, it means there's a bug in one of the drivers involved.

Also, the last time I tried FUSE it was shaky and unreliable. Work is ongoing to improve that.
 
Honestly, I thought that kernel panics when writing files via fuse was standard. Has anyone gotten this to work? I get panics when writing via both ntfs-3g and sshfs.

Adam
 
Also, the last time I tried FUSE it was shaky and unreliable. Work is ongoing to improve that.
Click to expand...
Before the update and with another drive there were no issues for me :)

Honestly, I thought that kernel panics when writing files via fuse was standard. Has anyone gotten this to work? I get panics when writing via both ntfs-3g and sshfs.
Click to expand...
I don't use sshfs. Unfortunatly there is no better solution for making the backup incremental and readable on windows machines :(


It does. If --bw-limit fixes things, it means there's a bug in one of the drivers involved.
Click to expand...
Would be nice if I came so far.. I think we nearly found the source of all evil :)

When I connect the drive to the FreeBSD maschine I get following data:
Code: 
camcontrol devlist
<WDC WD20EARS-00MVWB0 51.0AB51>    at scbus0 target 0 lun 0 (ada0,pass0)
<WDC WD5000AAKX-001CA0 15.01H15>   at scbus1 target 0 lun 0 (ada1,pass1)
<WDC WD20EARS-00MVWB0 51.0AB51>    at scbus2 target 0 lun 0 (ada2,pass2)
<WDC WD10EARS-003BB1 80.00A80>     at scbus3 target 0 lun 0 (ada3,pass3)
<Generic  6000>                    at scbus4 target 0 lun 0 (pass4,da0)
<WD Elements 1042 1007>            at scbus5 target 0 lun 0 (pass5)

Code: 
usbconfig
ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen1.1: <XHCI root HUB 0x1b21> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE
ugen2.1: <EHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen0.2: <product 0x0024 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen2.2: <product 0x0024 vendor 0x8087> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen2.3: <USB2.0 Card Reader Generic       ,   .> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen2.4: <Elements 1042 Western Digital> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON

Interesting is that:
Code: 
<WD Elements 1042 1007>            at scbus5 target 0 lun 0 (pass5)
the usb drive doesn't get signed in /dev but the internal hdd:
Code: 
<WDC WD5000AAKX-001CA0 15.01H15>   at scbus1 target 0 lun 0 (ada1,pass1)

Another weird thing is that the internal drive (ada1) gets listed in /dev as an bsd-labeled drive.
Code: 
ada1s1a
ada1s1b
ada1s1c
ada1s1d
ada1s1e
ada1s1f

When I now try to mount one of the slices:
Code: 
ntfs-3g /dev/ada1s /mnt
Failed to access '/dev/ada1s': No such file or directory
Please check '/dev/ada1s' and the ntfs-3g binary permissions,
and the mounting user ID. More explanation is provided at
http://tuxera.com/community/ntfs-3g-faq/#unprivileged
server ~ # ntfs-3g /dev/ada1s1 /mnt
Error opening '/dev/ada1s1': Operation not permitted
Failed to mount '/dev/ada1s1': Operation not permitted
The NTFS partition is hibernated. Please resume and shutdown Windows
properly, or mount the volume read-only with the 'ro' mount option, or
mount the volume read-write with the 'remove_hiberfile' mount option.
For example type on the command line:

            mount -t ntfs-3g -o remove_hiberfile /dev/ada1s1 /mnt
mount /dev/ada1s1b /mnt
mount: /dev/ada1s1b : Operation not permitted

mount /dev/ada1s1d /mnt
mount: /dev/ada1s1d : Device busy
I am getting various error messages.


Any suggestions?
 
Yes,

Code: 
mount -t ntfs-3g -o remove_hiberfile /dev/ada1s1 /mnt
mount: /dev/ada1s : Operation not permitted
 
Yes, as root.

I now plugged the device to another FreeBSD maschine.

Same issue. So it's the drive or the formatting.

I will format the drive again under Unix in NTFS.
The Windows quick formatting is crap
 
So I now formated the drive again with parted.

When view at the progress of camcontrol devlist than I see that first
FreeBSD probes the device, assignes it to da1 and than to pass.

Is there a way how I can assign the drive manuelly

Can it be that FreeBSD lost the ability to detect ntfs-drives with the upgrade to 9?
 
USB2.0
Code: 
Apr  4 10:16:36 server kernel: ugen2.5: <Western Digital> at usbus2
Apr  4 10:16:36 server kernel: umass1: <MSC Bulk-Only Transport> on usbus2
Apr  4 10:16:36 server kernel: umass1:  SCSI over Bulk-Only; quirks = 0x4101
Apr  4 10:16:36 server kernel: umass1:7:1:-1: Attached to scbus7
Apr  4 10:16:55 server kernel: (da1:umass-sim1:1:0:0): got CAM status 0x4
Apr  4 10:16:55 server kernel: (da1:umass-sim1:1:0:0): fatal error, failed to attach to device
Apr  4 10:16:55 server kernel: (da1:umass-sim1:1:0:0): lost device - 0 outstanding
Apr  4 10:16:56 server kernel: (da1:umass-sim1:1:0:0): removing device entry

USB3.0
Code: 
Apr  4 10:20:08 server kernel: ugen2.5: <Western Digital> at usbus2 (disconnected)
Apr  4 10:20:08 server kernel: umass1: at uhub4, port 3, addr 5 (disconnected)
Apr  4 10:20:16 server kernel: ugen1.2: <Western Digital> at usbus1
Apr  4 10:20:16 server kernel: umass1: <MSC Bulk-Only Transport> on usbus1
Apr  4 10:20:16 server kernel: umass1:  SCSI over Bulk-Only; quirks = 0x4101
Apr  4 10:20:16 server kernel: umass1:7:1:-1: Attached to scbus7
Apr  4 10:20:18 server kernel: da1 at umass-sim1 bus 1 scbus7 target 0 lun 0
Apr  4 10:20:18 server kernel: da1: <WD Elements 1042 1007> Fixed Direct Access SCSI-6 device 
Apr  4 10:20:18 server kernel: da1: 400.000MB/s transfers
Apr  4 10:20:18 server kernel: da1: 476938MB (976769024 512 byte sectors: 255H 63S/T 60801C
 
Ok so the conclusion:

FreeBSD can't assign the drive to a /dev file when using USB2.0. I looked through google and found many theories like not enough power. Under USB3.0 the drive gets assigned but here # ntfs-3g fails entirely. # mount_ntfs can mount ro.

So there is a combination from hardware compatibility and failure of ntfs-3g.
 
Maybe this is poking around in the fog, but what does SMART say of the disc in question?

edit: bad power connection could leave traces in the smart log for crc errors by causing brown outs in the circuits.
 
Maybe this is poking around in the fog, but what does SMART say of the disc in question?
Click to expand...
SMART says everything great :)

edit: bad power connection could leave traces in the smart log for crc errors by causing brown outs in the circuits.
Click to expand...
The strange thing is that I tried the drive on equal hardware with linux/windows and there was no issue with USB2.0.
 
You must log in or register to reply here.
Back
Top