On Sun, Apr 02, 2006 at 06:07:21PM +0100, Ron Yorston wrote: > A couple of years ago there was a discussion on lkml under the thread > 'PATCH - ext2fs privacy (i.e. secure deletion) patch' about zapping > deleted data in the filesystem as a security mechanism. The discussion > wandered off into how 'chattr +s' could be implemented and whether > encrypting filesystems wouldn't be a better solution to the problem. > > I've been maintaining a simplified version of the patch for a different > reason: to keep filesystems in files sparse. Filesystem images for use > by things like user-mode Linux and Xen are often created as sparse files. > After they've been in use for a while their sparseness is reduced even > though they may have lots of free space. Having the guest kernel fill > deleted blocks with zeros doesn't make the underlying file sparse, > but it does help. I've got a page with more details: > > http://intgat.tigress.co.uk/rmy/uml/sparsify.html > > Anyway, a couple of things: > > 1. The patch (see below) is pretty simple. I've been using it for some > time in UML build systems for old versions of software (rh62, anyone?), > and today I even tried it for several seconds in a Xen domU kernel. > It seems to do what I want, but is it any good? > > 2. The patch is now for ext2 only, the original ext3 version having > succumbed to bitrot. What would it take to implement something > similar for ext3 these days? Well, I think this should be optional, if included. It does directly counteract the patch I recently sent to salvage files from their data blocks in ext2/ext3. Best regards keld _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users