Subject: Re: [netatalk-admins] Trash problems
From: PayPC System Mail Subscriber (spammail@quanta.paypc.com)
Date: Mon Sep 28 1998 - 11:31:27 EDT
> This is actually the only thing that's keeping me from switching from
> mac servers to netatalk, the mac users get nervous over this behaviour,
> and don't trust the Linux box....
>
> The Permissions/Trash Can/DID problem is perhaps only a small problem,
> but probably keeps many from switching to netatalk..
Actually.. the solution I've come up with seems to work the "best" for me and
probably for those who don't have TOO many netatalk users.
Set the Network Trash Folder's permissions to read-only access group+others,
owned by root (or the netatalk admin account). pre-create the trash can
directories, each owned by the various users... rwx owner only, no access to
others or group at all (in other words, mode 0700).
You could write a script to do this easily enough... it sounds like it's a
pain, but it's not that bad. I have 10 users here and it took a few minutes
(I used BBEdit, cutting and pasting, etc. then pasted the commands into my
shell, and I was done - 2 minutes).
Not a very "elegant" solution, but now everyone who mounts the volumes get
their own (private) trash can, and they all work as they should, and my
security models aren't compromised, AND I didn't need to patch netatalk
(which would require RE-patching everytime it changed).
I have no idea what happens if more than one instance of the same user tries
to mount the same share -- maybe netatalk's locking semantics do what they
should? I dunno. We don't have that problem here.
Adrian: on another note, what sort of performance improvement areas would you
think are best pursued. I seem to get very high transfer rates (with
inferior os's like Windows NT) with SAMBA - but with netatalk, I get no more
than about 600-650k/sec with netatalk. Would read-ahead/prediction code
help? Larger i/o buffers perhaps? Or perhaps read/write overlapping
technology
read case
---------
Request for 100k arrives
[ 16k chunk comes in off disk] -- netatalk starts to send it down the
wire....
by the time the 16k chunk's sent, the rest of the 84k has arrived from disk
and can continue being sent w/o delay.
This way, the data gets sent to the client a few milliseconds sooner (at
least). [I'm assuming 10baset ethernet and SCSI harddrives of at least
1.5Mb/s or greater and no fragmentation].
Write case is similar, except it begins writing the data after a certain
fraction of the data has arrived... with systems like Linux which cache so
much and intelligently (write-accumulation happens almost all of the time),
perhaps this isn't much of a gain, since people who write to a Linux system
always feel like they're writing to a RAM disk (assuming the system's been
quiescent long enough for updated to flush its dirty buffers).
Anyhow - it seems like netatalk/AppleShare could be quite a bit faster. When
i use protocols like FTP, I get the ethernet limit all of the time to/from
the same box (1,200,000 bytes/sec, measured against wall-clock).
(By the way, I do realise many of the performance issues are in the
Appleshare client, but from the settings I've seen in the 3.7.x and 3.8
clients (write-behind/read-ahead, large buffers, separate cache buffers,
etc), it seems like it really should fly.
=Rob=
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:19 EST