[PATCH v8 00/24] xfsprogs: online scrub support

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

 



Hi all,

This is the eighth revision of a patchset that adds to XFS kernel
support for mapping multiple file logical blocks to the same physical
block (reflink/deduplication), implements the beginnings of online
metadata scrubbing and preening, and implements reverse mapping for
the realtime device.  There shouldn't be any incompatible on-disk
format changes, pending a thorough review of the patches within.

The first few patches implement the GETFSMAP ioctl and xfs_io support
for testing.  Following that are ports of the kernel patches that
touch libxfs/, and the customary xfs_io support for that as well.

The huge patch at the end implements xfs_scrub, which is a tool that
walks the file system to find and check as much metadata as it can.
scrub/generic.c and scrub/xfs.c both contain large comments
documenting exactly how scrub works, so I will not rehash them in
great depth here.

We aggressively use XFS' online metadata scrub features to scour all
per-AG and per-FS metadata.  Then, we use BULKSTAT, open_by_handle,
GETBMAPX, and online scrub to rapidly examine every inode and extent
map in the filesystem.  Finally, if data extent scrubbing is switched
on, we use GETFSMAP to find physical extents that need scanning --
with rmap enabled, we can narrow it down to target only file data
blocks; without it, the bnobt backend to GETFSMAP provides us a map of
the free space, which is good enough to (over)scan the disk.  If the
underlying disks are SCSI devices, we can issue READ VERIFY commands
to do the verify without consuming wire bandwidth.

If you're going to start using this mess, you probably ought to just
pull from my github trees for kernel[1], xfsprogs[2], xfstests[3],
xfs-docs[4], and man-pages[5].  The kernel patches in the git trees
should apply to 4.8-rc3; xfsprogs patches to for-next; and xfstest to
master.

The patches have been xfstested with x64, ppc64, and armhf; all tests
in the clone and rmap groups pass.  AFAICT they don't cause any new
failures for the 'auto' group.

This is an extraordinary way to eat your data.  Enjoy! 
Comments and questions are, as always, welcome.

--D

[1] https://github.com/djwong/linux/tree/djwong-devel
[2] https://github.com/djwong/xfsprogs/tree/djwong-devel
[3] https://github.com/djwong/xfstests/tree/djwong-devel
[4] https://github.com/djwong/xfs-documentation/tree/djwong-devel
[5] https://github.com/djwong/man-pages/tree/djwong-devel

_______________________________________________
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