On Mon, Jan 09, 2006 at 09:44:26AM +0000, Hugh Dickins wrote:
> On Sun, 8 Jan 2006, Linus Torvalds wrote:
> >
> > Code like that should use "set_page_dirty()", which does the appropriate
> > callbacks to the filesystem for that page. I wonder if the bug is simply
> > because the ST code just sets the dirty bit without telling anybody else
> > about it...
>
> Yes, it should be using set_page_dirty_lock(), and that is already known
> about (I have patches for this and similar sg.c, but the sg.c case is
> tougher and not yet finished); but entirely irrelevant to Ryan's case.
>
> Quite apart from the fact that he's doing backups to tape (not dirtying
> the memory from this driver), you'll find that it even passes dirty 0
> when reading into the memory (another bug; whereas sg.c conversely says
> it's always dirtying when it isn't). So there's no point in Ryan
> fiddling with the SetPageDirty.
One thing I forgot to mention was that 2.6.11.3 had the problem too when
I reverted to it. I remember now that the person who made the debian
bug report for this said it only happened with a 64-bit userspace - and
I switched from a 32- to 64-bit userspace when I did 2.6.11 -> 2.6.14
(and I'm too lazy to switch back).
To get the backups back, I just ran a recent kernel with
try_direct_io=0. If there's nothing further for me to test at this
time, I guess I'll go back to doing that until there's something to try.
Is that OK?
-ryan
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
