On Thu, 2002-05-16 at 13:33, Christoph Hellwig wrote:
> On Thu, May 16, 2002 at 11:06:50AM -0500, Steve Lord wrote:
> > This allows Linux XFS to support filesystem blocksizes of less than
> > a page. So powers of 2 from 512bytes to 4Kbytes on an ia32. It also
> > switches more of the xfs I/O path to use the generic code used by
> > other filesystems, the write path is still specific to XFS, but this
> > too should change over time.
> >
> > It has had pretty extensive testing, and we have no known problems
> > on 4K filesystems, I do have one failure in fsx on a 1K block filesystem
> > which shows after a few hundred thousand interations. We will continue
> > to work on that one.
> >
> > There is also a repair problem on small blocksizes. You should upgrade
> > commands, but apart from some changes in repair there have been no changes
> > there which are necessary for the small block support.
>
> So far I just had a short look over the diffs and the changes look really
> nice. It's good to see the VM intrusions (mostly) gone and the VOPs now
> removed also looked very strange for someone having done on vnode based
> filesystems (just SVR4, not IRIX) :)
>
> Two nitpicks I found:
>
> - traversing inode->i_dirty_buffers and inode->i_dirty_data_buffers needs
> the lru_list_lock, thus both the old and the new version are (at least
> in theory) racy, maybe just use inode_has_buffers() instead?
It is not exported right now, so I would have to add that, this is
VN_DIRTY you are talking about right? Both the places we use that
may be dead meat anyway, we should have true inode dirty management
now as a side effect of this change. I have not really investigated
that part of things yet.
> - a ClearPageDelalloc macro is missing and PG_delalloc is directly cleared
> in filemap.c. Yes, I see the excuse that Andrea did the same mistake
> with PG_launder but he already fixed that in his tree. As a I plan to
> merge that over before 2.4.19 maybe you could fix PG_delalloc also in
> that merge.
Done.
>
> Will take a closer look at the changes now.
If you can find the place where we do not zero part of a page when
writing into a hole in the file in the block size < pagesize case
that would be great! fsx_linux runs a few hundred thousand ops
before it finds that. I have been staring at the code too hard
for too long to see it right now.
>
> Christoph
Steve
|