It is a Lacie d2 quadra drive but FreeBSD reports this;
server kernel: ad4: 953869MB <Hitachi HDS721010KLA330 GKAOA70M> at ata2-master 

When I perform the RSYNC I receive these errors

Oct 24 12:47:13 server kernel: ad4: FAILURE - device detached
Oct 24 12:47:13 server kernel: subdisk4: detached
Oct 24 12:47:13 server kernel: ad4: detached
Oct 24 12:47:13 server kernel: g_vfs_done():ad4s1a[WRITE(offset=144332767232, 
length=131072)]error = 6
Oct 24 12:47:13 server kernel: g_vfs_done():ad4s1a[WRITE(offset=144332898304, 
length=131072)]error = 6
The write failure messages keep on being issued until the server reboots. It 
isn't in the log, but I receive a dirty buffer panic.

I don't have easy access to a 7.1 system with an ESATA port.

I'm current redoing the entire process, wipe, build filesystem, mount, rsync 
using the USB port. If that works I'm going to junk the idea of using the ESATA 
card for the drive.

Can you recommend an ESATA card that fits in an PCI slot since my server 
doesn't have a PCI-E slot?

Mark Jacobs

-----Original Message-----
From: Jeremy Chadwick [mailto:[EMAIL PROTECTED]
Sent: Fri 10/24/2008 7:09 PM
To: Jacobs, Mark - Data Center Operations <[EMAIL PROTECTED]>
Subject: Re: Drive Disconnection
On Fri, Oct 24, 2008 at 02:02:41PM -0400, Mark Jacobs wrote:
> I have an external Lacie 1Tb drive attached to a FreeBSD 6.4-PRERELEASE
> system via an ESATA connection.
> atapci0: <SiI SiI 3512 SATA150 controller>
> I cleaned off the drive by writing random data to it. The write took
> overnight and didn't experience any problems. I then added a filesystem
> to the drive and mounted it on the system.
> However when I perform an rsync backup from a FreeBSD 7.1 PRERELEASE
> system to the drive over an NFS connection the drive disconnects and the
> server reboots.

You've not provided enough information to help track this down.  What
model/brand of disk is attached to that controller?  What does smartctl
-a have to say about the disk?  What gets printed on the console before
it reboots?  Do you have the same problem if you run

> Does anyone have an idea where to go from here?

The only generic advice I can give you at this point) is to avoid
Silicon Image controllers, particularly their SATA controllers.  They
have a history of causing data corruption on Linux, FreeBSD, and
Windows, and some have reported other miscellaneous problems with them
as well.  There's not enough evidence in this thread so far to blame the
SiI controller, but when I see them, I become immediately suspicious.

| Jeremy Chadwick                                jdc at |
| Parodius Networking              |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to