public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Amit Gud <amitgud@gmail.com>
To: Chris Wedgwood <cw@f00f.org>
Cc: linux-kernel@vger.kernel.org, gud@eth.net
Subject: Re: Using filesystem blocks
Date: Fri, 3 Sep 2004 10:26:23 +0530	[thread overview]
Message-ID: <2c6b3ab0040902215656704680@mail.gmail.com> (raw)
In-Reply-To: <20040902200743.GB6875@taniwha.stupidest.org>

> 
> > Is it wise enough to abstract away the usage of blocks for storing
> > extended attributes?
> 
> No.  Some fs' will store xattr data in the inodes if it fits.
> 

First up, why is mbcache code is written at VFS layer than being
filesystem specific? Neccessarily to take away the coding overheads of
maintaining block cache that any filesystem uses, even though given
that only ext2 and ext3 uses it. It facilitates code reuse.

Now if we are making reuse of the code to manage block cache, why
can't we make use of the code of allocating blocks, storing the stuff
and other intricacies of block boundary management by writing the code
at another layer, which other fs' can use readiliy including ext2
ext3?

This is advantageous for new filesystems or new fs features which may
use disk blocks not assiciated with any inode for some purpose. Right
now if I'm to do, I'II have to rewrite the code of whole block
management. But I can avail the block cache functions of mbcache.

Like I said, forget what fs does what to store its xattr, ext2/3 is
just an example which uses blocks to store them. What I'm pointing to
is generic interface to the block management code. If the block
management code is written with a generic interface, like mbcache, it
would be very helpful for the future filesystems or for new features
in the exiting fs'.

AG

  reply	other threads:[~2004-09-03  4:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-02 19:29 Using filesystem blocks Amit Gud
2004-09-02 20:07 ` Chris Wedgwood
2004-09-03  4:56   ` Amit Gud [this message]
2004-09-03  8:19     ` Christoph Hellwig
2004-09-03 12:06       ` Amit Gud

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=2c6b3ab0040902215656704680@mail.gmail.com \
    --to=amitgud@gmail.com \
    --cc=cw@f00f.org \
    --cc=gud@eth.net \
    --cc=linux-kernel@vger.kernel.org \
    /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