--MXxcbiX/Q4+iy5U7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 19, 2006 at 01:57:12PM +0200, joel@carnat.net wrote:
  | What about having a NFS server serving (external) USB2 disks ?
  |=20
  | I'm thinking about turning my Athlon64 barebone into a NFS server but
  | there is only room for one disk. So I thought I might plug extra disk v=
ia
  | USB2.

My experience with external USB storage leads me to recommend
against using it for production use.

I've been using IDE & SATA disks in various external USB<->IDE
shims for doing disk->disk backups (with rsync -c, dump(8) to file,
tar(8) to file, etc).

The common USB<->IDE chipsets have the following issues:

    *	They don't handle errors in a graceful manner; a bad block
	on the IDE disk can result in the process accessing the block
	getting stuck in disk wait for a long period of time.
	When it does finally return an error, the information
	is fairly useless.
	(Contrast this with the helpful FSBN error retry messages
	from the wd(4) layer).
	Fortunately, I can generally recover from lock-ups
	by disconnecting the USB cable; the kernel detaches the
	devices and the process exits.

    *	You can't access the SMART data on the IDE disk, since they
	present the disk as a fairly "dumb" SCSI disk.
	Accessing the SCSI mode pages doesn't generally work either.
	On a related note, you can't access the raw IDE identity
	information either (often that's faked into the different-
	sized SCSI product/vendor fields).

    *	Performance is generally "OK" for raw throughput (25MiB/s),
	contrasted with the native (45-60MiB/s).


I've considered using IEEE1394<->IDE, but the support for that in
NetBSD isn't production quality.

Another promising option is eSATA:
	http://en.wikipedia.org/wiki/SATA#External_SATA
I haven't had the opportunity to use this technology yet,
and I don't know how well the NetBSD ATAPI layer supports
hot-plug, which is a necessity for my problem-space.


YMMV.


cheers,
Luke.

--MXxcbiX/Q4+iy5U7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iD8DBQFFEL5vpBhtmn8zJHIRAjZQAJ0df0pmRKoAaDPLTUVk3/dPqQvnTgCdGvLY
HMTfjNMC80AgXguI7l6R4cM=
=AvEE
-----END PGP SIGNATURE-----

--MXxcbiX/Q4+iy5U7--