On Tue, Jul 04, 2006 at 09:10:11AM +0200, Constantin Gonzalez wrote:
> Hi Eric,
>
> Eric Schrock wrote:
> > You don't need to grow the pool. You should always be able truncate the
> > file without consuming more space, provided you don't have snapshots.
> > Mark has a set of fixes in testing whic
Hi Eric,
Eric Schrock wrote:
> You don't need to grow the pool. You should always be able truncate the
> file without consuming more space, provided you don't have snapshots.
> Mark has a set of fixes in testing which do a much better job of
> estimating space, allowing us to always unlink files
That's excellent news, as with the frequency that customers applications
go feral and write a whole heap of crap (or they don't watch closely
enough with gradual filling) we will forever be getting calls if this
functionality is *anything* but transparent...
Most explorers I see have filesystem 10
You don't need to grow the pool. You should always be able truncate the
file without consuming more space, provided you don't have snapshots.
Mark has a set of fixes in testing which do a much better job of
estimating space, allowing us to always unlink files in full pools
(provided there are no s
Hi,
of course, the reason for this is the copy-on-write approach: ZFS has
to write new blocks first before the modification of the FS structure
can reflect the state with the deleted blocks removed.
The only way out of this is of course to grow the pool. Once ZFS learns
how to free up vdevs this
On a system still running nv_30, I've a small RaidZ filled to the brim:
2 3 [EMAIL PROTECTED] pts/9 ~ 78# uname -a
SunOS mir 5.11 snv_30 sun4u sparc SUNW,UltraAX-MP
0 3 [EMAIL PROTECTED] pts/9 ~ 50# zfs list
NAME USED AVAIL REFER MOUNTPOINT
mirpool1 33.6G 0
