Does someone know the history which led to the EPERM for unlink() of
directories on ZFS? Why was this done this way, and not something like
allowing the unlink and execute it on the next scrub or remount?
Lionel
___
zfs-discuss mailing list
Does someone know the history which led to the EPERM for unlink() of
directories on ZFS? Why was this done this way, and not something like
allowing the unlink and execute it on the next scrub or remount?
It's not about the unlink(), it's about the link() and unlink().
But not allowing link
2012-06-14 19:11, tpc...@mklab.ph.rhul.ac.uk wrote:
In message 201206141413.q5eedvzq017...@mklab.ph.rhul.ac.uk,
tpc...@mklab.ph.r
hul.ac.uk writes:
Memory: 2048M phys mem, 32M free mem, 16G total swap, 16G free swap
My WAG is that your zpool history is hanging due to lack of
RAM.
in solaris zfs cache many things, you should have more ram
if you setup 18gb swap , imho, ram should be high than 4gb
regards
Sent from my iPad
On Jun 25, 2012, at 5:58, tpc...@mklab.ph.rhul.ac.uk wrote:
2012-06-14 19:11, tpc...@mklab.ph.rhul.ac.uk wrote:
In message
I don't know the precise history, but I think its a mistake to permit direct
link() or unlink() of directories. I do note that on BSD (MacOS at least)
unlink returns EPERM if the executing user is not superuser. I do see that the
man page for unlink() says this on illumos:
The decision to not support link(2) of directories was very deliberate - it
is an abomination that never should have been allowed in the first place.
My guess is that the behavior of unlink(2) on directories is a direct
side-effect of that (if link isn't supported, then why support unlink?).
Also
The decision to not support link(2) of directories was very deliberate - it
is an abomination that never should have been allowed in the first place.
My guess is that the behavior of unlink(2) on directories is a direct
side-effect of that (if link isn't supported, then why support unlink?).
Also
Eric Schrock eric.schr...@delphix.com wrote:
The decision to not support link(2) of directories was very deliberate - it
is an abomination that never should have been allowed in the first place.
My guess is that the behavior of unlink(2) on directories is a direct
side-effect of that (if link
On Mon, Jun 25, 2012 at 11:19 AM, casper@oracle.com wrote:
In the very beginning, mkdir(1) was a set-uid application; it used
mknod to make a directory and then created a link from
newdir to newdir/.
and from
. to newdir/..
Interesting, guess you learn something new
Eric Schrock eric.schr...@delphix.com wrote:
On Mon, Jun 25, 2012 at 11:19 AM, casper@oracle.com wrote:
In the very beginning, mkdir(1) was a set-uid application; it used
mknod to make a directory and then created a link from
newdir to newdir/.
and from
. to
I ran into something odd today:
zfs destroy -r random/filesystem
is mindbogglingly slow. But seems to me, it shouldnt be.
It's slow, because the filesystem has two snapshots on it. Presumably, it's
busy rolling back the snapshots.
but I've already declared by my command line, that I DONT CARE
On Jun 25, 2012, at 10:55 AM, Philip Brown wrote:
I ran into something odd today:
zfs destroy -r random/filesystem
is mindbogglingly slow. But seems to me, it shouldnt be.
It's slow, because the filesystem has two snapshots on it. Presumably, it's
busy rolling back the snapshots.
but
12 matches
Mail list logo
