[PATCH 00/50] xfsprogs: patch queue for crc-dev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi folks,

This is the latest patchset for the crc-dev branch of xfsprogs.
It follows up on the last series of 22 patches to get libxf sin sync
with the kernel code but adding all the changes from the kernel size
to remove __KERNEL__ from the code. Hence there's a fair bit more
code churn in the patch set, but overall the diffstat is a
significant reduction in code in libxfs. Like the kernel side
patchset, there is a lot of new files that are shared with the
kernel, and the diffstat reflects that:

90 files changed, 3573 insertions(+), 4863 deletions(-)
 rename include/{xfs_buf_item.h => xfs_buf_item_format.h} (62%)
 delete mode 100644 include/xfs_dfrag.h
 create mode 100644 include/xfs_dquot_format.h
 rename include/{xfs_extfree_item.h => xfs_extfree_item_format.h} (69%)
 create mode 100644 include/xfs_icreate_item.h
 create mode 100644 include/xfs_icreate_item_format.h
 delete mode 100644 include/xfs_inode.h
 create mode 100644 include/xfs_inode_buf.h
 create mode 100644 include/xfs_inode_fork.h
 rename include/{xfs_inode_item.h => xfs_inode_item_format.h} (61%)
 delete mode 100644 include/xfs_log.h
 create mode 100644 include/xfs_log_format.h
 delete mode 100644 include/xfs_log_priv.h
 delete mode 100644 include/xfs_mount.h
 delete mode 100644 include/xfs_quota.h
 create mode 100644 include/xfs_quota_defs.h
 delete mode 100644 include/xfs_rtalloc.h
 create mode 100644 include/xfs_rtalloc_defs.h
 delete mode 100644 include/xfs_symlink.h
 create mode 100644 include/xfs_symlink_remote.h
 delete mode 100644 include/xfs_trans.h
 create mode 100644 include/xfs_trans_format.h
 create mode 100644 include/xfs_trans_resv.h
 create mode 100644 libxfs/xfs_inode_buf.c
 rename libxfs/{xfs_inode.c => xfs_inode_fork.c} (82%)
 create mode 100644 libxfs/xfs_log_rlimit.c
 rename libxfs/{xfs_mount.c => xfs_sb.c} (94%)
 rename libxfs/{xfs_symlink.c => xfs_symlink_remote.c} (68%)
 rename libxfs/{xfs_trans.c => xfs_trans_resv.c} (67%)

Overall, it's a significant reduction in the amount of code, and it
cleans up quite a bit of the nasty header file dependency issues as
the majority of the new shared header files are not dependent on
each other. Having header files like xfs_mount.h, xfs_trans.h,
xfs_log.h and xfs_log_priv.h no longer present in userspace makes a
big difference to the clarity of the libxfs header files...

The only other major addition to the series is Jeff Liu's
log reservation calculation patchset, which allows mkfs to calculate
the minmum log size based on log reservation sizes rather than
transaction reservation sizes. This causes a significant increase in
the default size of the log for small filesystems - many xfstests now
fail because the default log size doesn't fit inside a 16MB
AG anymore. Hence mkfs will need some further tweaking here to avoid
those failures. xfs/216 gives a pretty good overview of the
difference in default sizes:

 QA output created by 216
-fssize=1g log      =internal log           bsize=4096   blocks=2560, version=2
-fssize=2g log      =internal log           bsize=4096   blocks=2560, version=2
-fssize=4g log      =internal log           bsize=4096   blocks=2560, version=2
-fssize=8g log      =internal log           bsize=4096   blocks=2560, version=2
-fssize=16g log      =internal log           bsize=4096   blocks=2560, version=2
-fssize=32g log      =internal log           bsize=4096   blocks=4096, version=2
+fssize=1g log      =internal log           bsize=4096   blocks=4896, version=2
+fssize=2g log      =internal log           bsize=4096   blocks=4896, version=2
+fssize=4g log      =internal log           bsize=4096   blocks=4896, version=2
+fssize=8g log      =internal log           bsize=4096   blocks=4896, version=2
+fssize=16g log      =internal log           bsize=4096   blocks=4896, version=2
+fssize=32g log      =internal log           bsize=4096   blocks=4896, version=2
 fssize=64g log      =internal log           bsize=4096   blocks=8192, version=2

Which indicate worst case log reservation is roughly 2x larger than
the worst case transaction reservation for small filesystems. I'm
surprised that we haven't had more problems with this in the past
than we have...

Thoughts, comments, flames?

Cheers,

Dave.

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux