Hi Ted:
> Um, how much testing have you done with this patch in place? The
> change to call_filldir() was part of other changes in how
> call_filldir() was called, and at least in the common case where
> filldir() returns -EINVAL because there's not enough room in the
> user's readdir buffer and the entry needs to be saved for the next
> getdents() systemcall, the code is correct.
>
> In fact, I haven't tried your patch, but I'm pretty certain that if
> applied, it will cause directory entries to be dropped such that rm
> -rf for large hierarchies will *always* fail because some files won't
> get deleted becuase they won't be returned by readdir().
>
> What kernel version were you running when you were testing ext4 using
> bonnie? If you are using a kernel older than 2.6.28-rc2 (and newer
> than 2.6.27-rc4), I would guess what you ran into was a known bug that
> was fixed by commit 3c37fc86.
Thanks much. Yes, now I see how the commit above works with the existing code.
I'm running a 2.6.26-based kernel with various patches applied from
the ext4 patch queue. We don't have this commit in our base, hence my
patch works (at least with basic testing) there. But I can see how it
would not work with the current base kernel (where this commit is
incorporated).
Sorry for the confusion; but this does point out a problem of mine:
where should I be looking for ext4 patches? I've been using
http://repo.or.cz/w/ext4-patch-queue.git
where I'm not seeing this patch (am I just missing it?). Should I
simply be using
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git
where in fact I am seeing this patch?
Thanks,
Curt
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
