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 in full pools
> (provided there are no snapshots, of course).  This provides much more
> logical behavior by reserving some extra slop.

is this a planned and not yet implemented functionality or why did Tatjana
see the "not able to rm" behaviour?

Or should she use unlink(1M) in these cases?

Best regards,
   Constantin

> 
> - Eric
> 
> On Mon, Jul 03, 2006 at 02:23:06PM +0200, Constantin Gonzalez wrote:
>> 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 may become a better solution because you can then
>> shrink the pool again after the rming.
>>
>> I expect many customers to run into similar problems and I've already gotten
>> a number of "what if the pool is full" questions. My answer has always been
>> "No file system should be used up more than 90% for a number of reasons", but
>> in practice this is hard to ensure.
>>
>> Perhaps this is a good opportunity for an RFE: ZFS should reserve enough
>> blocks in a pool in order to always be able to rm and destroy stuff.
>>
>> Best regards,
>>    Constantin
>>
>> P.S.: Most US Sun employees are on vacation this week, so don't be alarmed
>> if the really good answers take some time :).
> 
> --
> Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

-- 
Constantin Gonzalez                            Sun Microsystems GmbH, Germany
Platform Technology Group, Client Solutions                http://www.sun.de/
Tel.: +49 89/4 60 08-25 91                   http://blogs.sun.com/constantin/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to