> I had previously applied the linux "patch-2.4.4" to a 2.4.3-xfs tree and
> examined the rejects
> comparing it to the recent patch "linux-2.4.4-xfs-TEST.patch"
>
> The "unsigned char s_posix_acl_flag" in "struct super_block" in
> "include/linux/fs.h" is between two longs "s_flags" and "s_magic" this
> produces the worst packing of a structure is it intended to be in the same
> cache line or some other reason? tucking it after "unsigned char s_dirt"
> would have a better packing, I think.
yep that does appear to be a dumb place to put it.
>
> The "unsigned long block[]" and "ulong block[]" declarations are back in
> "drivers/md/lvm-snap.c" "lvm_snapshot_COW" and "lvm_write_COW_table_block"
> was it intended to return to local arrays?
Hmm, looks like the patch is out of date here, they are defined this way in
the tree now:
unsigned long blocks[KIO_MAX_SECTORS];
ulong blocks[1];
>
> The b_dev vs b_rdev in drivers/md/lvm.c 1111 "MINOR(bh->b_rdev) and 1140
> "kdevname(bh->b_rdev)" also have disapeared Jens Axboe's comment about
> destroyed stacking devices made me leery in this section.
Also changed in the development tree.
>
> There also were files that may have been left over "merge#conflicts" and
> "fs/iobuf.2.4.4.c"
No comment - except it wasn't me!
One day we might get the patch process going fast enough, but for now,
the message remains that if you really want to follow the development
the only real way to do it is to usr the cvs tree.
Thanks for the comments, I will reorder the fields in the superblock.
Steve
|