Matthias Andree:
> On Fri, 18 Feb 2011, Wietse Venema wrote:
>
> > Please file a ZFS bug reportug. As per POSIX, when the O_CREAT is
> > specified to open(),
> >
> > The third argument does not affect whether the file is open
> > for reading, writing or for both.
> >
> > In other words, read/write access is controlled with the O_RDWR flags,
> > not the read/write permissions argument.
> >
> > When the above error happens, Postfix discards the file. Consequently,
> > Postfix performance will be reduced, because it creates one extra file
> > per MAIL transaction, instead of one extra file over the process
> > lifetime.
>
> That being said, I found ZFS performance abysmal, that is with a
> single-disk pool (one partition on an enterprise-class 7200/min HDD,
> amd64, 4 GB DDR3 ECC RAM, Phenom II X4 905e i. e. 4 x 2.5 GHz) on
> FreeBSD 8.X, and ZFS prefetching enabled in the loader tunable.
>
> I'd been running /usr with compression enabled, and stat() effort,
> writes, and thereabouts were unbearably slow, even with a 85% filled
> partition (the pool was 100% full one time before). I've switched to
> UFS2 on a 5400/min eco-consumer-class drive for the nonce and it just
> flies. I haven't analyzed this, but it seems there still are a few
> rough edges in ZFS-on-FreeBSD that need to be filed down a bit :)
Let me guess: the eco-consumer-class drive was running with write
caching enabled. I remember achieving better latencies on a $500
computer than with a (small) server whose disk alone cost hundreds.
> Note that ZFS on FreeBSD also still has a bug that it can't delete files
> if the partition is full. You need to manually truncate files (to create
> room for the relevant deletion log entries) before you can remove files.
> (I've file a problem report for that but don't know the PR # yet.)
Will ZFS allow non-root users to fill up the whole disk?
Wietse
