public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Young <sean@mess.org>
To: Charles Manning <manningc2@actrix.gen.nz>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH] forget block layer request for FTLs
Date: Fri, 25 Nov 2005 02:42:11 +0100	[thread overview]
Message-ID: <20051125014211.GA22740@atlantis.8hz.com> (raw)
In-Reply-To: <200511251336.41191.manningc2@actrix.gen.nz>

On Fri, Nov 25, 2005 at 01:36:41PM +1300, Charles Manning wrote:
> On Friday 25 November 2005 02:21, Sean Young wrote:
> > Any flash device which appears as a normal block device to user space
> > has a flash translation layer (FTL) which from time to time garbage
> > collects, i.e. moves data around to make room for an erase. Data might
> > be moved from one erase unit to another, so a full erase unit can be
> > erased without losing data.
> >
> > The FTL is unaware of any "unused" sectors; e.g. if a file is
> > unlinked the sectors where the data of that (former) file resides will
> > still be considered for garbage collection, even though those sectors
> > are no longer relevant.
> >
> > The purpose of this patch is to make it possible for file system drivers
> > to inform the block device of "staleness" of no-longer-used sectors.  This
> > patch introduces another barrier request, REQ_FORGET. The semantics
> > of this requests are that no read() is expected before the next write(),
> > i.e. read() may return garbage in the time between forget() and the
> > next write().
> 
> Being a bit of a flash-head, I find this RPC quite interesting. I am 
> struggling though to see exactly where this is going to be used. 
> 
> >From what I understand, you're going to have file knowledge passed into the 
> block driver and need a special fs to exploit this. This is starting to break 
> down the whole point of a block driver isn't it?
> 
> Perhaps if you hacked a fs to use this that would show the benefits.

In the patch (see previous mail) the fat file systems call 
blkdev_issue_forget() in fat_free_clusters(). So, on file unlink the 
block device gets a forget request for the data sectors where the 
file previously existed. 

Also, the patch augments the resident flash disk FTL to use this 
request; those sectors are simply removed and if an entire erase unit
is full of "deleted" (or overwritten) sectors, it is erased. I've tested
this and it really does reduce the number of erases in certain 
circumstances.

This same request could be handled in other FTLs and CFA ATA.

So, no special file system is required nor is file system knowledge present
in the block device driver. Of course, this only helps in case there is an
FTL. Flash-aware file systems like jffs have far smarter ways of dealing
with this. However FTLs are used in so many devices nowadays.


Sean

  reply	other threads:[~2005-11-25  1:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-24 13:21 [RFC PATCH] forget block layer request for FTLs Sean Young
2005-11-25  0:36 ` Charles Manning
2005-11-25  1:42   ` Sean Young [this message]
2005-11-27 17:54   ` Sean Young
2005-11-25 10:55 ` Jörn Engel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051125014211.GA22740@atlantis.8hz.com \
    --to=sean@mess.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=manningc2@actrix.gen.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox