On Tue, 2002-06-18 at 13:52, Luciano Chavez wrote:
> Steve,
>
> Thank you much for the speedy reply! My page_buf.c didn't quite look
> like yours (I assume this was the _pagebuf_page_io routine). I made the
> following change to version of the source and it now appears to be
> working.
>
> int concat_ok=0; /* <---- I initialized this to zero */
> /*
> if ((MAJOR(dev) != LVM_BLK_MAJOR) && (MAJOR(dev) != MD_MAJOR)) {
> concat_ok = 1;
> } else if ((MAJOR(dev) == MD_MAJOR) && (pg_offset == 0) &&
> (pg_length == PAGE_CACHE_SIZE) &&
> ((bn & ((page_buf_daddr_t)(PAGE_CACHE_SIZE - 1) >>
> 9)) == 0)) {
> concat_ok = 1;
> } else {
> concat_ok = 0;
> }
> */
>
> Will the recommended code change be the permanent fix?
My problem with this is the overhead it adds to the XFS metadata
I/O path. My preferred solution is the version 2 log code and
striping the log - and ideally mkfs would be able to tell what it
was being run on and tell you to use striping.
>
> > The code I have sitting here introduces a new log format in xfs which can
> > be aligned on different boundaries. It introduces new mkfs options:
> >
> > -l version=2,sunit=xxxx
> >
> > Log writes then become aligned on and padded to the stripe unit specified,
> > 4K is enough in most cases. You can also do larger logwrites with this code,
> > but that is not the issue here.
> >
>
> What about non-striped devices? How are they aligned now?
That was the any 512 byte boundary for any 512 byte length up to 32K.
i.e. they are 512 byte aligned, but unless the code you commented
out is turned off, or we are talking to a device type we know cannot
cope with this, we will attempt to write a 4K page on a non 4K disk
offset.
Steve
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|