On 27 jan 2010, at 10.44, Björn JACKE wrote:
> On 2010-01-25 at 08:31 -0600 Mike Gerdts sent off:
>> You are missing the point. Compression and dedup will make it so that
>> the blocks in the devices are not overwritten with zeroes. The goal
>> is to overwrite the blocks so that a back-end storage device or
>> back-end virtualization platform can recognize that the blocks are not
>> in use and as such can reclaim the space.
>
> a filesystem that is able to do that fast would have to implement something
> like unwritten extents.
Rather what is needed is files with holes, as what is expected here is more
free space in the file system when the unused parts of the file is punched out.
With F_ALLOCSP, you would still not be able to use the space and there would be
no gain.
> Some days ago I experimented to create and allocate
> huge files on ZFS ontop of OpenSolaris using fnctl and F_ALLOCSP which is
> basically the same thing that you want to do when you zero out space. It takes
> ages because it actually writes zeroes to the disk. A filesystem that knows
> the
> concept of unwritten extents finishes the job immediately. There are no real
> zeros on the disk but the extent is tagged to be unwritten (you get zeros when
> you read it).
Files with holes are implemented, and as far as I know they are fast too:
-bash-4.0$ cat hole.py
f = open('foo', 'w')
f.write('x')
f.seek(2**62)
f.write('y')
f.close()
-bash-4.0$ time python hole.py
real 0m0.019s
user 0m0.010s
sys 0m0.009s
-bash-4.0$ ls -la foo
-rw-r--r-- 1 ragge staff 4611686018427387905 Jan 28 00:26 foo
> Are there any plans to add unwritten extent support into ZFS or any reason why
> not?
I have no idea, but just out of curiosity - when do you want that?
/ragge
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
