On Fri, 2002-06-28 at 01:52, Hiroyuki Nakano wrote:
> Hi Steve,
>
> I attempted to ascertain what this problem happened, as I read
> XFS source program. But I don't understand a thing. Can you
> see what happened ?
I happened to be sitting next to another filesystem developer
when I read this, and he remembered an old ext2 race condition.
I think I understand what is happening - and how to fix it, the
only problem is that fixing it will potentially be a major
performance issue - so the question is, why do you need this to
work? Would a solution which disallowed block access to the
device when it was mounted be sufficient, or do you really
want to look at metadata live via the block device. The
xfsdump program does not need this, the only thing which does
is running xfs_db on a live filesystem, but that is not really
of use to anyone but developers.
Steve
>
> Thanks.
>
> -nak
>
>
> > Hi Steve,
> >
> > I executed Shell-scrippt, as I changed lseek second argument value
> > to 4096*12, 4096*14, 4096*15, 4096*17, 4096*18, 4096*20 from 4096*16.
> > Shell-script was normal end. Only 4096*16(10000H) is a problem.
> >
> > Physical address 10000H-13fffH is inode chunk area on dev/hda7.
> > I think
> > Inode chunk area is in page buffers. Read function access to page
> > buffers.
> > If read function access to device, page buffers are broken.
> >
> >
|