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.. /Tomas -- Tomas Ögren, st...@acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Umeå `- Sysadmin at {cs,acc}.umu.se _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
