linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Andreas Dilger <adilger@turbolabs.com>
Cc: Christian Laursen <xi@borderworlds.dk>,
	linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: Ext2 directory index, updated
Date: Tue, 6 Nov 2001 01:38:15 +0100	[thread overview]
Message-ID: <20011106003705Z17274-18972+251@humbolt.nl.linux.org> (raw)
In-Reply-To: <20011104022659Z16995-4784+750@humbolt.nl.linux.org> <20011104230046Z17057-18972+12@humbolt.nl.linux.org> <20011105151006.G3957@lynx.no>
In-Reply-To: <20011105151006.G3957@lynx.no>

On November 5, 2001 11:10 pm, Andreas Dilger wrote:
> On Nov 05, 2001  00:01 +0100, Daniel Phillips wrote:
> > For using the -o index option on a non-throwaway volume, we should do 
this:
> > 
> >  void ext2_add_compat_feature (struct super_block *sb, unsigned feature)
> >  {
> > +	return;
> >  	if (!EXT2_HAS_COMPAT_FEATURE(sb, feature))
> >  	{
> > 
> > And afterwards you can rm -rf your test directory, though actually normal 
> > ext2 shouldn't see anything unusual about it.  The real reason for rm'ing 
the 
> > test directory is so that I can tweak the index format in upcoming 
prerelease 
> > versions.
> 
> Well, e2fsck _should_ really know about the fact that there are indexed
> directories in the filesystem, which is what the COMPAT flag flag is for.
> The only current issue is that e2fsck doesn't understand this compat flag.
> 
> > I've disabled the add_compat_feature here for now, because until fsck can 
> > handle it, it just causes trouble.  I'll go read Andreas' writeup on the 
> > COMPAT flags again and see if I can come up with a more friendly 
> > interpretation.
> 
> No, COMPAT is the friendliest.  It means old kernels can read/write this
> filesystem without problems, just that e2fsck can't/won't check it.  Even
> though an old fsck _probably_ won't break such a filesystem, there is no
> guarantee of that,

Well, it's hard to see how the fsck could hurt, since all the blocks of the 
directory look like legitimate empty blocks.  When did 

> and it definitely won't validate the indexes, so a
> "successfull" fsck of an indexed directory doesn't mean anything until it
> can understand this COMPAT flag.
> 
> That said, I agree that turning the COMPAT flag off for short term testing
> is probably not fatal, but I thought we were not going to even suggest
> using non-throwaway filesystems until the hash function was finalized?

True.  Right now, I'm interested in finding out exactly how the old fscks are 
going to behave when they run into indexed directories, so I'll leave the 
COMPAT flag off for now and turn it back on when we hit the first 
format-frozen release.  The method of restoring a partition to a fsckable 
state is easy to document:

    # debugfs -w root_fs
    debugfs: feature -dir_index

Anybody who's running the patch will have access to a recent version of 
debugfs that knows about the dir_index flag.

> In
> the end, if an updated e2fsck detects the DIR_INDEX flag (and valid indexes
> therein) it will turn on the COMPAT flag for us, so all will be well.  I
> don't advise that we push for patch inclusion until e2fsck is done, however.

Yes, as long as testers heed my warning and stick to test partitions there's 
no particular danger.  There's a simple recovery procedure for anyone who 
doesn't want to bother re-mkfsing the partition.  We're in pretty good shape. 

My improved show_buckets routine is working code that could be used to get 
started on the new fsck code.  It walks the index in hash bucket order 
dumping out statistics, and, together with the checks in dx_probe, basically 
defines the index format.

--
Daniel

  reply	other threads:[~2001-11-06  0:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-04  2:28 Ext2 directory index, updated Daniel Phillips
2001-11-04  2:44 ` Daniel Phillips
2001-11-04 22:09 ` Christian Laursen
2001-11-04 22:24   ` Daniel Phillips
2001-11-04 22:54     ` Christian Laursen
2001-11-04 23:01     ` Daniel Phillips
2001-11-04 23:09       ` Gábor Lénárt
2001-11-05 22:10       ` Andreas Dilger
2001-11-06  0:38         ` Daniel Phillips [this message]
2001-11-05  1:43   ` Daniel Phillips
2001-11-05  7:48     ` Ville Herva
2001-11-05  9:53       ` Daniel Phillips
2001-11-05 22:59     ` Christian Laursen
2001-11-05 23:13       ` Daniel Phillips
2001-11-05 23:45         ` Andreas Dilger
2001-11-08  7:21     ` Christian Laursen
  -- strict thread matches above, loose matches on Subject: below --
2002-03-04 11:03 Ext2 Directory Index, updated Daniel Phillips
2001-11-02  3:36 Ext2 directory index, updated Daniel Phillips
2001-11-02  5:04 ` Andreas Dilger

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=20011106003705Z17274-18972+251@humbolt.nl.linux.org \
    --to=phillips@bonn-fries.net \
    --cc=adilger@turbolabs.com \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xi@borderworlds.dk \
    /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;
as well as URLs for NNTP newsgroup(s).