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
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 lat
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 me
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 inn
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 i
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
> rat
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 inde
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 th
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 routin
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 princi
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 o
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
> > ext2_next_entr
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 ind
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 for
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
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 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 h
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
> wil
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 onl
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 a
> 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:
http://nl.linux.org/~phillips/htree/dx.pcache-2.4
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 ftp.math.psu.edu/pub/viro/ext2-dir-patch-S
> 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 unsubscr
On Thu, 12 Apr 2001, Alexander Viro wrote:
> Folks, IMO ext2-dir-patch got to the stable stage. Currently
> it's against 2.4.4-pre2, but it should apply to anything starting with
> 2.4.2 or so.
>
> Ted, could you review it for potential inclusion into 2.4 once
> it gets enough test
30 matches
Mail list logo