Andre van Eyssen wrote:
On Wed, 29 Jul 2009, Andriy Gapon wrote:
Well, I specifically stated that this property should not be
recursive, i.e. it
should work only in a root of a filesystem.
When setting this property on a filesystem an administrator should
carefully set
permissions to make sure that only trusted entities can create
directories there.
Even limited to the root of a filesystem, it still gives a user the
ability to consume resources rapidly. While I appreciate the fact that
it would be restricted by permissions, I can think of a number of usage
cases where it could suddenly tank a host. One use that might pop up,
for example, would be cache spools - which often contain *many*
directories. One runaway and kaboom.
No worse than any other use case, if you can create datasets you can do
that anyway. If you aren't running with restrictive resource controls
you can "tank" the host in so many easier ways. Note that the proposal
is that this be off by default and has to be something you explicitly
enable.
We generally use hosts now with plenty of RAM and the per-filesystem
overhead for ZFS doesn't cause much concern. However, on a scratch box,
try creating a big stack of filesystems - you can end up with a pool
that consumes so much memory you can't import it!
'rmdir' question requires some thinking, my first reaction is it
should do zfs
destroy...
.. which will fail if there's a snapshot, for example. The problem seems
to be reasonably complex - compounded by the fact that many programs
that create or remove directories do so directly - not by calling
externals that would be ZFS aware.
I don't understand how you came to that conclusion. This wouldn't be
implemented in /usr/bin/mkdir but in the ZFS implementation of the
mkdir(2) syscall.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
