Re: [GSoC 2013] Implement file system flags to scrub data blocks before deletion

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

On Thu, May 16, 2013 at 09:34:06PM +0200, Przemys?aw Sieroci?ski wrote:
> Hello,
> 
> I have received some comments on my project proposal, which can be found
> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/psie/1
>  ,
> however it would be great if I could detail more points.
> 
> May I ask about your opinion on:
> 1) What file system(s) besides ffs and ext2fs could be modified to
> benefit users,

A better question would be: can this be done in a file system independent
way?  Or, at least, how can you minimize the number of file system specific
changes?
It's good to consider doing things for more than one filesystem, but I
wouldn't worry too much about what others to support.  I think you'll
have plenty to keep you busy with just these two.

> 2) What user space binaries have to be changed?

One of the things you have on your list is "write a custom binary for mount",
and you don't mention modifying the standard mount program until much later.
If initially all you need is a flag to specify whether scrubbing should be on 
or not, I think you'll find that modifying mount_ffs will be much easier
than trying to re-write it.

A few questions that come to mind:
  Currently, removing a file is a relatively fast, atomic operation.  Are
  you planning on guaranteeing that the file is wiped before the unlink
  returns, potentially making the time to unlink much longer?  Or, will you
  end up with a list of blocks to clear after the unlink returns?

  Will the code that does the wiping be a part of the kernel, or
  are you thinking to hand that off to a userland process?  (perhaps
  similar to lfs_cleanerd)

  Do all file deletions wipe the data blocks, or are you going to
  provide a way for the rm command to pick and choose?

  Are you planning on wiping blocks when a file is truncated too?

Consider these, and come up with a few use cases of your own, and I'll
bet that will naturally lead you in to which binaries might need to be
adjusted.

Eric