On Jul 28, 2009, at 8:53 AM, Tomas Ögren wrote:
On 28 July, 2009 - David Gwynne sent me these 1,9K bytes:
On 27/07/2009, at 10:14 PM, Tobias Exner wrote:
Hi list,
I've did some tests and run into a very strange situation..
I created a zvol using "zfs create -V" and initialize an sam-
filesystem on this zvol.
After that I restored some testdata using a dump from another
system.
So far so good.
After some big troubles I found out that releasing files in the sam-
filesystem doesn't create space on the underlying zvol.
So staging and releasing files just work until the "zfs list"
shows me
a zvol with 100% usage although the sam-filesystem was only filled
up
to 20%.
I didn't create snapshots and a scrub did show any errors.
When the zvol was filled up even a sammkfs can't solve the
problem. I
had to destroy the zvol ( not zpool ).
After that I was able recreate a new zvol with sam-fs on top.
this is a feature of block devices. once you (or samfs) uses a
block on
the zvol, it has no mechanism to tell the zvol when it is no longer
using it. samfs simply unreferences the blocks it frees, it doesnt
actively go through them and tell the block layer underneath it that
they can be reclaimed. from the zvols point of view theyre still
being
used because they were used at some point in the past.
http://en.wikipedia.org/wiki/TRIM_(SSD_command) should make it
possible
I guess.. (assuming it's implemented all the way in the chain)..
Should/could help in virtualization too..
Or just enable compression and zero fill.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
