From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?U8OpYmFzdGllbiBXYWNxdWlleg==?= Subject: Re: Btrfs and raw zvol-like partition Date: Sun, 12 Apr 2009 20:32:29 +0200 Message-ID: <49E233BD.8050700@enix.org> References: <49E197BC.40703@enix.org> <2a31deca0904120613s56d8570pc1403284afcac094@mail.gmail.com> Reply-To: sw@enix.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed To: linux-btrfs@vger.kernel.org Return-path: In-Reply-To: <2a31deca0904120613s56d8570pc1403284afcac094@mail.gmail.com> List-ID: Andrey Kuzmin a =C3=A9crit : > zvol (interface) does not just 'export raw device' but rather > implements volume abstraction and integrates volume management into > file-system. > =20 Yep. I suck at writing english, thanks for pointing that out :) I surely mislead myself, but I think that the "volume management" of ZF= S=20 could be done with file. Alloc on write ? Use sparse file. Resizing ? Append or truncate the=20 file. Snapshot ? Snapshot the file. Another Volume ? An other file :) In fact, the two thinks that have to be done, for me, is : 1/ Optimise the different layer to bypass permission, acl, & co, and=20 surely the way data is written. 2/ Be able to export those file directly as block device. (Allowing=20 some more optimisation :) ) It's why I called this feature "export raw device" (as in "export raw=20 file as block device"). As I say, it could be emulated with file and=20 loopback, but it'll surely be slow ... So I wanna know if btrfs plan to= =20 have those type of optimization (and the user land tools to simplify=20 it's management). Regards, S=C3=A9bastien Wacquiez -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html