On 26 June 2012 14:51, wrote:
>
>>> To be honest, I think we should also remove this from all other
>>> filesystems and I think ZFS was created this way because all modern
>>> filesystems do it that way.
>>
>>This may be wrong way to go if it breaks existing applications which
>>rely on this feat
On 25 June 2012 11:33, wrote:
>
>>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
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
On 28 May 2012 22:10, Richard Elling wrote:
> The only recommendation which will lead to results is to use a
> different OS or filesystem. Your choices are
> - FreeBSD with ZFS
> - Linux with BTRFS
> - Solaris with QFS
> - Solaris with UFS
> - Solaris with NFSv4, use ZFS on independent fileserver
On Mon, May 28, 2012 at 9:06 PM, Iwan Aucamp wrote:
> I'm getting sub-optimal performance with an mmap based database (mongodb)
> which is running on zfs of Solaris 10u9.
>
> System is Sun-Fire X4270-M2 with 2xX5680 and 72GB (6 * 8GB + 6 * 4GB) ram
> (installed so it runs at 1333MHz) and 2 * 300GB
