Sorry, I couldn't think of any good flames that haven't already been
posted so I thought I'd be boring and post some code. ;-)
On Monday 14 May 2001 23:50, Daniel Phillips wrote:
> On Monday 14 May 2001 20:33, Andreas Dilger wrote:
> > Daniel, you write:
> > > Now, if the check routine tells
Sorry, I couldn't think of any good flames that haven't already been
posted so I thought I'd be boring and post some code. ;-)
On Monday 14 May 2001 23:50, Daniel Phillips wrote:
On Monday 14 May 2001 20:33, Andreas Dilger wrote:
Daniel, you write:
Now, if the check routine tells us how
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
> Daniel writes:
> > I was originally thinking we should give the admin the ability to
> > create a nonindexed directory if desired, and that's how it used to
> > be before we changed the setting of INDEX_FL from directory
> > creation time to
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
> Maybe we can have a "noindex" mount option for this?
We need that regardless, I just keep forgetting to put it in. I assume
the semantics are obvious: no new indexes are created but existing ones
are maintained. I.e., -o noindex does not
On Monday 14 May 2001 20:33, Andreas Dilger wrote:
> Daniel, you write:
> > Now, if the check routine tells us how much good data it found we
> > could use that to set a limit for the dirent scan, thus keeping the
> > same robustness as the old code but without having all the checks
> > in the
Daniel writes:
> On Thursday 10 May 2001 09:21, Andreas Dilger wrote:
> > I have changed the code to do the following:
> > - If the COMPAT_DIR_INDEX flag is set at mount/remount time, set the
> > INDEX mount option (the same as "mount -o index"). This removes
> > the need to specify the "-o
On Monday 14 May 2001 20:33, Andreas Dilger wrote:
> Danie, you write:
> > This can go in ext2_bread, which already has dir-specific code in
> > it (readahead), and ext2_getblk remains generic, for what it's
> > worth.
>
> Note that the dir-specific code in ext2_bread() is not readahead, but
>
Danie, you write:
> This can go in ext2_bread, which already has dir-specific code in it
> (readahead), and ext2_getblk remains generic, for what it's worth.
Note that the dir-specific code in ext2_bread() is not readahead, but
rather directory block pre-allocation, which would totally break
Danie, you write:
This can go in ext2_bread, which already has dir-specific code in it
(readahead), and ext2_getblk remains generic, for what it's worth.
Note that the dir-specific code in ext2_bread() is not readahead, but
rather directory block pre-allocation, which would totally break
On Monday 14 May 2001 20:33, Andreas Dilger wrote:
Danie, you write:
This can go in ext2_bread, which already has dir-specific code in
it (readahead), and ext2_getblk remains generic, for what it's
worth.
Note that the dir-specific code in ext2_bread() is not readahead, but
rather
Daniel writes:
On Thursday 10 May 2001 09:21, Andreas Dilger wrote:
I have changed the code to do the following:
- If the COMPAT_DIR_INDEX flag is set at mount/remount time, set the
INDEX mount option (the same as mount -o index). This removes
the need to specify the -o index option
On Monday 14 May 2001 20:33, Andreas Dilger wrote:
Daniel, you write:
Now, if the check routine tells us how much good data it found we
could use that to set a limit for the dirent scan, thus keeping the
same robustness as the old code but without having all the checks
in the inner loop.
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
Maybe we can have a noindex mount option for this?
We need that regardless, I just keep forgetting to put it in. I assume
the semantics are obvious: no new indexes are created but existing ones
are maintained. I.e., -o noindex does not mean
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
Daniel writes:
I was originally thinking we should give the admin the ability to
create a nonindexed directory if desired, and that's how it used to
be before we changed the setting of INDEX_FL from directory
creation time to later, when
On Thursday 10 May 2001 09:21, Andreas Dilger wrote:
> I previously wrote:
> > I was looking at the new patch, and I saw something that puzzles
> > me. Why do you set the EXT2_INDEX_FL on a new (empty) directory,
> > rather than only setting it when the dx_root index is created?
> >
> > Setting
On Thursday 10 May 2001 09:21, Andreas Dilger wrote:
I previously wrote:
I was looking at the new patch, and I saw something that puzzles
me. Why do you set the EXT2_INDEX_FL on a new (empty) directory,
rather than only setting it when the dx_root index is created?
Setting the flag
On Sunday 13 May 2001 00:18, Alexander Viro wrote:
> On Sat, 12 May 2001, Andreas Dilger wrote:
> > We could use the "buffer_uptodate" flag on the buffer to signal
> > that the block has been checked. AFAIK, a new buffer will not be
> > uptodate, and once it is it will not be read from disk
On Saturday 12 May 2001 23:41, Andreas Dilger wrote:
> Daniel writes:
> > Oh yes, I'm well aware it, that's what I mean by the "bullet
> > proofing" item on my to-do list. I don't quite agree with the idea
> > of embedding the checking of directory entry format inside the
> > ext2_get_page
On Sat, 12 May 2001, Andreas Dilger wrote:
> We could use the "buffer_uptodate" flag on the buffer to signal that
> the block has been checked. AFAIK, a new buffer will not be uptodate,
> and once it is it will not be read from disk again... However, if a
> user-space process read the buffer
Daniel writes:
> Oh yes, I'm well aware it, that's what I mean by the "bullet proofing"
> item on my to-do list. I don't quite agree with the idea of embedding
> the checking of directory entry format inside the ext2_get_page
> routine, it should be moved outside ext2_get_page, on basic
Daniel writes:
Oh yes, I'm well aware it, that's what I mean by the bullet proofing
item on my to-do list. I don't quite agree with the idea of embedding
the checking of directory entry format inside the ext2_get_page
routine, it should be moved outside ext2_get_page, on basic principal.
On Sat, 12 May 2001, Andreas Dilger wrote:
We could use the buffer_uptodate flag on the buffer to signal that
the block has been checked. AFAIK, a new buffer will not be uptodate,
and once it is it will not be read from disk again... However, if a
user-space process read the buffer would
On Sunday 13 May 2001 00:18, Alexander Viro wrote:
On Sat, 12 May 2001, Andreas Dilger wrote:
We could use the buffer_uptodate flag on the buffer to signal
that the block has been checked. AFAIK, a new buffer will not be
uptodate, and once it is it will not be read from disk again...
On Saturday 12 May 2001 23:41, Andreas Dilger wrote:
Daniel writes:
Oh yes, I'm well aware it, that's what I mean by the bullet
proofing item on my to-do list. I don't quite agree with the idea
of embedding the checking of directory entry format inside the
ext2_get_page routine, it
On Friday 11 May 2001 18:34, Andreas Dilger wrote:
> Al writes:
> > On Fri, 11 May 2001, Andreas Dilger wrote:
> > > I've tested again, now with kdb, and the system loops in
> > > ext2_find_entry() or ext2_add_link(), because there is a
> > > directory with a zero rec_len. While the actual cause
Al writes:
> On Fri, 11 May 2001, Andreas Dilger wrote:
> > I've tested again, now with kdb, and the system loops in ext2_find_entry()
> > or ext2_add_link(), because there is a directory with a zero rec_len.
> > While the actual cause of this problem is elsewhere, the fact that
> >
On Friday 11 May 2001 09:10, Andreas Dilger wrote:
> and previously wrote:
> > OK, here are the patches described above.
> >
> > Unfortunately, they haven't been tested. I've given them several
> > eyeballings and they appear OK, but when I try to run the ext2
> > index code (even without "-o
On Fri, 11 May 2001, Andreas Dilger wrote:
> I've tested again, now with kdb, and the system loops in ext2_find_entry()
> or ext2_add_link(), because there is a directory with a zero rec_len.
> While the actual cause of this problem is elsewhere, the fact that
> ext2_next_entry() will loop
I previously wrote:
> OK, here are the patches described above.
>
> Unfortunately, they haven't been tested. I've given them several
> eyeballings and they appear OK, but when I try to run the ext2 index code
> (even without "-o index" mount option) my system deadlocks somwhere
> inside my
I previously wrote:
OK, here are the patches described above.
Unfortunately, they haven't been tested. I've given them several
eyeballings and they appear OK, but when I try to run the ext2 index code
(even without -o index mount option) my system deadlocks somwhere
inside my ext2i module
On Fri, 11 May 2001, Andreas Dilger wrote:
I've tested again, now with kdb, and the system loops in ext2_find_entry()
or ext2_add_link(), because there is a directory with a zero rec_len.
While the actual cause of this problem is elsewhere, the fact that
ext2_next_entry() will loop
On Friday 11 May 2001 09:10, Andreas Dilger wrote:
and previously wrote:
OK, here are the patches described above.
Unfortunately, they haven't been tested. I've given them several
eyeballings and they appear OK, but when I try to run the ext2
index code (even without -o index mount
On Friday 11 May 2001 18:34, Andreas Dilger wrote:
Al writes:
On Fri, 11 May 2001, Andreas Dilger wrote:
I've tested again, now with kdb, and the system loops in
ext2_find_entry() or ext2_add_link(), because there is a
directory with a zero rec_len. While the actual cause of this
On Thursday 10 May 2001 22:53, Andreas Dilger wrote:
> OK, here are the patches described above.
>
> The first one changes the use of the various INDEX flags, so that
> they only appear when we have mounted with "-o index" (or
> COMPAT_DIR_INDEX) and actually created an indexed directory.
>
> The
On Wednesday 09 May 2001 23:22, you wrote:
> Daniel writes [re index directories]:
> > This is lightly tested and apparently stable.
>
> I was looking at the new patch, and I saw something that puzzles me.
> Why do you set the EXT2_INDEX_FL on a new (empty) directory, rather
> than only setting
I previously wrote:
> I have changed the code to do the following:
> - If the COMPAT_DIR_INDEX flag is set at mount/remount time, set the
> INDEX mount option (the same as "mount -o index"). This removes
> the need to specify the "-o index" option each time for filesystems
> which already
I previously wrote:
> I was looking at the new patch, and I saw something that puzzles me.
> Why do you set the EXT2_INDEX_FL on a new (empty) directory, rather
> than only setting it when the dx_root index is created?
>
> Setting the flag earlier than that makes it mostly useless, since it
>
I previously wrote:
I have changed the code to do the following:
- If the COMPAT_DIR_INDEX flag is set at mount/remount time, set the
INDEX mount option (the same as mount -o index). This removes
the need to specify the -o index option each time for filesystems
which already have
On Wednesday 09 May 2001 23:22, you wrote:
Daniel writes [re index directories]:
This is lightly tested and apparently stable.
I was looking at the new patch, and I saw something that puzzles me.
Why do you set the EXT2_INDEX_FL on a new (empty) directory, rather
than only setting it when
On Thursday 10 May 2001 22:53, Andreas Dilger wrote:
OK, here are the patches described above.
The first one changes the use of the various INDEX flags, so that
they only appear when we have mounted with -o index (or
COMPAT_DIR_INDEX) and actually created an indexed directory.
The second
I previously wrote:
I was looking at the new patch, and I saw something that puzzles me.
Why do you set the EXT2_INDEX_FL on a new (empty) directory, rather
than only setting it when the dx_root index is created?
Setting the flag earlier than that makes it mostly useless, since it
will be
Daniel writes [re index directories]:
> This is lightly tested and apparently stable.
I was looking at the new patch, and I saw something that puzzles me.
Why do you set the EXT2_INDEX_FL on a new (empty) directory, rather
than only setting it when the dx_root index is created?
Setting the flag
Daniel writes [re index directories]:
This is lightly tested and apparently stable.
I was looking at the new patch, and I saw something that puzzles me.
Why do you set the EXT2_INDEX_FL on a new (empty) directory, rather
than only setting it when the dx_root index is created?
Setting the flag
This patch updates ext2_getblk and ext2_bread to use the ERR_PTR style
of error return. As Al Viro pointed out, this is a better way of doing
things for a function returning a pointer. This approach would have
prevented the bug I fixed with the previous patch. 20 20 hindsight,
and I can
This patch updates ext2_getblk and ext2_bread to use the ERR_PTR style
of error return. As Al Viro pointed out, this is a better way of doing
things for a function returning a pointer. This approach would have
prevented the bug I fixed with the previous patch. 20 20 hindsight,
and I can
Works fine now. I'll keep on testing.
Thanks a bunch,
Albert
Daniel Phillips wrote:
>
> > This combination against 2.4.4 won't allow directories to be moved.
> > Ex: mv a b #fails with I/O error. See attached strace.
> > But with ext2-dir-patch-S4 by itself, mv works as it should.
>
> Now it
> This combination against 2.4.4 won't allow directories to be moved.
> Ex: mv a b #fails with I/O error. See attached strace.
> But with ext2-dir-patch-S4 by itself, mv works as it should.
Now it also works with my index patch as it should:
This combination against 2.4.4 won't allow directories to be moved.
Ex: mv a b #fails with I/O error. See attached strace.
But with ext2-dir-patch-S4 by itself, mv works as it should.
Now it also works with my index patch as it should:
Works fine now. I'll keep on testing.
Thanks a bunch,
Albert
Daniel Phillips wrote:
This combination against 2.4.4 won't allow directories to be moved.
Ex: mv a b #fails with I/O error. See attached strace.
But with ext2-dir-patch-S4 by itself, mv works as it should.
Now it also
On Thursday 03 May 2001 03:15, you wrote:
> Hello Daniel,
> This combination against 2.4.4 won't allow directories to be moved.
> Ex: mv a b #fails with I/O error. See attached strace.
> But with ext2-dir-patch-S4 by itself, mv works as it should.
> Later,
> Albert
Thanks Albert, this was
On Thursday 03 May 2001 03:15, you wrote:
Hello Daniel,
This combination against 2.4.4 won't allow directories to be moved.
Ex: mv a b #fails with I/O error. See attached strace.
But with ext2-dir-patch-S4 by itself, mv works as it should.
Later,
Albert
Thanks Albert, this was easily
Hello Daniel,
This combination against 2.4.4 won't allow directories to be moved.
Ex: mv a b #fails with I/O error. See attached strace.
But with ext2-dir-patch-S4 by itself, mv works as it should.
Later,
Albert
Daniel Phillips wrote:
>
> > Patch is on
Hello Daniel,
This combination against 2.4.4 won't allow directories to be moved.
Ex: mv a b #fails with I/O error. See attached strace.
But with ext2-dir-patch-S4 by itself, mv works as it should.
Later,
Albert
Daniel Phillips wrote:
Patch is on
> Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz
Here is my ext2 directory index as a patch against your patch:
http://kernelnewbies.org/~phillips/htree/dx.pcache-2.4.4
Changes:
- COMBSORT macro replaced by custom sort code
- Most #ifdef CONFIG_EXT2_INDEX's changed
Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz
Here is my ext2 directory index as a patch against your patch:
http://kernelnewbies.org/~phillips/htree/dx.pcache-2.4.4
Changes:
- COMBSORT macro replaced by custom sort code
- Most #ifdef CONFIG_EXT2_INDEX's changed
Patch rediffed to 2.4.4, otherwise - no changes (2.4.4 has a
fix for ext2 race, but it's unrelated to the thing).
Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz
Please, help with testing.
Al
-
To
Patch rediffed to 2.4.4, otherwise - no changes (2.4.4 has a
fix for ext2 race, but it's unrelated to the thing).
Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz
Please, help with testing.
Al
-
To
57 matches
Mail list logo
