First, a disclaimer: I do not know how the zfs dataset destruction
is implemented in reality,but I can guess at least a couple of
legal variants for a slow destruction.
2012-06-25 21:55, Philip Brown wrote:
I ran into something odd today:
zfs destroy -r random/filesystem
is mindbogglingly slo
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 snapshot
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 CAR
Eric Schrock wrote:
> On Mon, Jun 25, 2012 at 11:19 AM, 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, g
On Mon, Jun 25, 2012 at 11:19 AM, 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 every day :-)
Eric Schrock 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 isn't supported, the
>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?).
>
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 w
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:
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 <2012061414
>
> 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 hangin
>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 &
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
zfs-discuss@o
13 matches
Mail list logo
