On Monday 16 April 2001 14:40, you wrote:
> Daniel, you write (re indexed directories):
> > Superblock Feature Flag
> > ---
> >
> > This is now incorporated. I use the following code:
> >
> > if (!EXT2_HAS_COMPAT_FEATURE(sb, EXT2_FEATURE_COMPAT_DIR_INDEX))
> > {
> >
Andreas, you wrote:
> Daniel, you write:
> > Andreas, you wrote:
> > > We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
> > > because the on-disk layout is 100% compatible with older kernels, so
> > > no reason to force read-only for those systems. I'm guessing Ted had
> > > put
Daniel, you write (re indexed directories):
> Superblock Feature Flag
> ---
>
> This is now incorporated. I use the following code:
>
> if (!EXT2_HAS_COMPAT_FEATURE(sb, EXT2_FEATURE_COMPAT_DIR_INDEX))
> {
> lock_kernel();
>
Daniel, you write (re indexed directories):
Superblock Feature Flag
---
This is now incorporated. I use the following code:
if (!EXT2_HAS_COMPAT_FEATURE(sb, EXT2_FEATURE_COMPAT_DIR_INDEX))
{
lock_kernel();
Andreas, you wrote:
Daniel, you write:
Andreas, you wrote:
We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
because the on-disk layout is 100% compatible with older kernels, so
no reason to force read-only for those systems. I'm guessing Ted had
put RO_COMPAT_BTREE_DIR in
On Monday 16 April 2001 14:40, you wrote:
Daniel, you write (re indexed directories):
Superblock Feature Flag
---
This is now incorporated. I use the following code:
if (!EXT2_HAS_COMPAT_FEATURE(sb, EXT2_FEATURE_COMPAT_DIR_INDEX))
{
Daniel, you write:
> Andreas, you wrote:
> > We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
> > because the on-disk layout is 100% compatible with older kernels, so
> > no reason to force read-only for those systems. I'm guessing Ted had
> > put RO_COMPAT_BTREE_DIR in there in
Andreas, you wrote:
> Daniel, you write:
> > So then, the obvious candidate would be:
> >
> > #define EXT2_FEATURE_RO_COMPAT_DIR_INDEX0x0004
> >
> > which was formerly EXT2_FEATURE_RO_COMPAT_BTREE_DIR.
>
> Actually not. We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
>
>Daniel Phillips wrote:
> > Jamie Lokier wrote:
> > > Daniel Phillips wrote:
> > > > ls already can't handle the directories I'm working with on a regular
> > > > basis. It's broken and needs to be fixed. A merge sort using log n
> > > > temporary files is not hard to write.
> > >
> > > ls -U |
Daniel Phillips wrote:
Jamie Lokier wrote:
Daniel Phillips wrote:
ls already can't handle the directories I'm working with on a regular
basis. It's broken and needs to be fixed. A merge sort using log n
temporary files is not hard to write.
ls -U | sort
should do
Andreas, you wrote:
Daniel, you write:
So then, the obvious candidate would be:
#define EXT2_FEATURE_RO_COMPAT_DIR_INDEX0x0004
which was formerly EXT2_FEATURE_RO_COMPAT_BTREE_DIR.
Actually not. We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
because the on-disk
Daniel, you write:
Andreas, you wrote:
We should go with "EXT2_FEATURE_COMPAT_DIR_INDEX 0x0008"
because the on-disk layout is 100% compatible with older kernels, so
no reason to force read-only for those systems. I'm guessing Ted had
put RO_COMPAT_BTREE_DIR in there in anticipation, but
Daniel, you write:
> OK, I get it. Nice article - it would sure be nice to see this
> incorporated Documentation/filesystems/ext2.txt. I just checked my copy
> of Understanding the Linux Kernel and while existence of the compat
> fields in the super block is noted, there is nothing at all said
Daniel Phillips wrote:
> Jamie Lokier wrote:
> > Daniel Phillips wrote:
> > > ls already can't handle the directories I'm working with on a regular
> > > basis. It's broken and needs to be fixed. A merge sort using log n
> > > temporary files is not hard to write.
> >
> > ls -U | sort
> >
> >
Andreas Dilger wrote:
> Daniel writes:
> > > Are you going to go to a COMPAT flag before final release? This is
> > > pretty much needed for e2fsck to be able to detect/correct indexes.
> >
> > I will if I know what the exact semantics are. I have only an
> > approximate idea of how this works
Jamie Lokier wrote:
> Daniel Phillips wrote:
> > ls already can't handle the directories I'm working with on a regular
> > basis. It's broken and needs to be fixed. A merge sort using log n
> > temporary files is not hard to write.
>
> ls -U | sort
>
> should do the trick.
Um, yep. Now ls
Jamie Lokier wrote:
Daniel Phillips wrote:
ls already can't handle the directories I'm working with on a regular
basis. It's broken and needs to be fixed. A merge sort using log n
temporary files is not hard to write.
ls -U | sort
should do the trick.
Um, yep. Now ls should do
Andreas Dilger wrote:
Daniel writes:
Are you going to go to a COMPAT flag before final release? This is
pretty much needed for e2fsck to be able to detect/correct indexes.
I will if I know what the exact semantics are. I have only an
approximate idea of how this works and I'd
Daniel Phillips wrote:
Jamie Lokier wrote:
Daniel Phillips wrote:
ls already can't handle the directories I'm working with on a regular
basis. It's broken and needs to be fixed. A merge sort using log n
temporary files is not hard to write.
ls -U | sort
should do the
Daniel, you write:
OK, I get it. Nice article - it would sure be nice to see this
incorporated Documentation/filesystems/ext2.txt. I just checked my copy
of Understanding the Linux Kernel and while existence of the compat
fields in the super block is noted, there is nothing at all said
Daniel Phillips wrote:
> ls already can't handle the directories I'm working with on a regular
> basis. It's broken and needs to be fixed. A merge sort using log n
> temporary files is not hard to write.
ls -U | sort
should do the trick.
-- Jamie
-
To unsubscribe from this list: send the
On Tuesday 10 April 2001 18:37, you wrote:
> Daniel Phillips writes:
> > The zeroth block of an indexed directory is the index root. Initially
> > the index has only one block. The following blocks are normal ext2
> > directory entry blocks. When the directory grows large enough to fill
> >
cat calahan.reply.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
cat calahan.reply.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tuesday 10 April 2001 18:37, you wrote:
Daniel Phillips writes:
The zeroth block of an indexed directory is the index root. Initially
the index has only one block. The following blocks are normal ext2
directory entry blocks. When the directory grows large enough to fill
all the
Daniel Phillips wrote:
ls already can't handle the directories I'm working with on a regular
basis. It's broken and needs to be fixed. A merge sort using log n
temporary files is not hard to write.
ls -U | sort
should do the trick.
-- Jamie
-
To unsubscribe from this list: send the line
Daniel writes:
> > Are you going to go to a COMPAT flag before final release? This is
> > pretty much needed for e2fsck to be able to detect/correct indexes.
>
> I will if I know what the exact semantics are. I have only an
> approximate idea of how this works and I'd appreciate a more precise
> Are you going to go to a COMPAT flag before final release? This is
> pretty much needed for e2fsck to be able to detect/correct indexes.
I will if I know what the exact semantics are. I have only an
approximate idea of how this works and I'd appreciate a more precise
definition.
> One thing
Daniel Phillips writes:
> The zeroth block of an indexed directory is the index root. Initially
> the index has only one block. The following blocks are normal ext2
> directory entry blocks. When the directory grows large enough to fill
> all the available entries in the root index block
Daniel Phillips writes:
The zeroth block of an indexed directory is the index root. Initially
the index has only one block. The following blocks are normal ext2
directory entry blocks. When the directory grows large enough to fill
all the available entries in the root index block (around
Are you going to go to a COMPAT flag before final release? This is
pretty much needed for e2fsck to be able to detect/correct indexes.
I will if I know what the exact semantics are. I have only an
approximate idea of how this works and I'd appreciate a more precise
definition.
One thing I
Daniel writes:
Are you going to go to a COMPAT flag before final release? This is
pretty much needed for e2fsck to be able to detect/correct indexes.
I will if I know what the exact semantics are. I have only an
approximate idea of how this works and I'd appreciate a more precise
Daniel, you write:
> For the past several weeks I have been developing a directory index
> facility for Ext2, with good results so far. This note describes the
> on-disk format of the new index.
Finally starting to test your last release, and you make a new one... ;-)
> Needless to say, the
For the past several weeks I have been developing a directory index
facility for Ext2, with good results so far. This note describes the
on-disk format of the new index.
The development work has reached the point where the format is nearly
ready to be frozen, so I hope that the material I have
For the past several weeks I have been developing a directory index
facility for Ext2, with good results so far. This note describes the
on-disk format of the new index.
The development work has reached the point where the format is nearly
ready to be frozen, so I hope that the material I have
Daniel, you write:
For the past several weeks I have been developing a directory index
facility for Ext2, with good results so far. This note describes the
on-disk format of the new index.
Finally starting to test your last release, and you make a new one... ;-)
Needless to say, the new
36 matches
Mail list logo
