Article View: fa.netbsd.tech.kern
Article #103Re: [GSoC 2013] Implement file system flags to scrub data blocks before deletion
From: Eric Haszlakiewicz
Date: Fri, 17 May 2013 05:29
Date: Fri, 17 May 2013 05:29
46 lines
3703 bytes
3703 bytes
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
Technical Details
Message-ID:
<fa.I8qIfm/Vf1H+j+BxlZEn1zG2ccY@ifi.uio.no>Path:
arc1-ca.pugleaf.net!bp1ni3310pbd.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!uio.no!nntp.uio.no!.POSTED!not-for-mailReferences:
<fa.sEAkPTH8tj0Hz+O4GjH/0NrdGQE@ifi.uio.no>Show Full Headers
Complete Article Headers
X-Google-Thread: b7e13b6095,c7d2965c68d9d35e
X-Google-Attributes: gidb7e13b6095,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.68.246.229 with SMTP id xz5mr7253733pbc.1.1368768562630;
Thu, 16 May 2013 22:29:22 -0700 (PDT)
Path: arc1-ca.pugleaf.net!bp1ni3310pbd.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!uio.no!nntp.uio.no!.POSTED!not-for-mail
From: Eric Haszlakiewicz <erh@nimenees.com>
Newsgroups: fa.netbsd.tech.kern
Subject: Re: [GSoC 2013] Implement file system flags to scrub data blocks
before deletion
Date: Fri, 17 May 2013 05:29:22 UTC
Organization: Internet mailing list
Lines: 46
Sender: tech-kern-owner@NetBSD.org
Message-ID: <fa.I8qIfm/Vf1H+j+BxlZEn1zG2ccY@ifi.uio.no>
References: <fa.sEAkPTH8tj0Hz+O4GjH/0NrdGQE@ifi.uio.no>
NNTP-Posting-Host: mail-jess.uio.no
Mime-Version: 1.0
X-Trace: readme.uio.no 1368768562 15938 129.240.7.9 (17 May 2013 05:29:22 GMT)
X-Complaints-To: abuse@uio.no
NNTP-Posting-Date: Fri, 17 May 2013 05:29:22 +0000 (UTC)
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: tech-kern@NetBSD.org
To: Przemys?aw Sieroci?ski <przsie@gmail.com>
Delivered-To: tech-kern@NetBSD.org
X-Virus-Scanned: amavisd-new at NetBSD.org
In-Reply-To: <CAFEq-UGvLSOKa-wEcY2qYcSe4gP8Cu6ySN06cZtuLxqQUkBZKA@mail.gmail.com>
List-Id: tech-kern.NetBSD.org
Original-Date: Fri, 17 May 2013 00:28:54 -0500
Original-Message-Id: <20130517052854.GA2261@nimenees.com>
Original-References: <CAFEq-UGvLSOKa-wEcY2qYcSe4gP8Cu6ySN06cZtuLxqQUkBZKA@mail.gmail.com>
Bytes: 3413
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline