[rescue] Happy New Year! RIP, Sun/Solaris...

[Peter Corlett]

On Wed, Jan 05, 2011 at 08:07:01AM -0500, Phil Stracchino wrote:
[...]
> Personally, I tend to think one should probably try to avoid NFS-sharing
> USB devices in the first place. But that said, kernel nfsd randomly
> crashing is quite sufficient reason on its own for me to avoid it.

I tend to avoid using USB-connected hard drives at all, as the performance
is awful and the components are cheap and nasty and prone to failure.
There's a reason the first few batches of a new hard drive manufacturing
process end up sitting in USB enclosures on the shelves of supermarkets
instead of going into datacentres to be driven hard.

One possible reason why USB and NFS interact badly is that the kernel stack
is being exhaused due to there being too many layers. But I'm not a kernel
hacker and not minded to investigate it. There's probably a compile-time
option for the Linux kernel to crank the stack size up a bit.

> Of course, there's also the point that the last time I looked at the Linux
> knfsd, its configuration ability was limited to "You can give it a list of
> shares to export. Who needs more configuration than that?"

The last time you looked at it was probably a long time ago.

> Oh, I dunno .... you think maybe I might like to be able to restrict what
> hosts can access them, or grant particular hosts norootsquash, or ... ?

On my home network, I grant a /22 read-only access to some shared file, and
a /24 read-write access. The ranges overlap and it still does the right
thing. I got about 110MB/s from it serving files to my Mac over a GigE
network, although in real use it's slower because the Linux box's disk can't
always keep up.