I think that xfsprogs-3.2 should be seriously considered for a round of stable keywording. Two reasons spring to mind. The first reason is that it is needed in order to support the v5 filesystem format. As observed by Phoronix: "The xfsprogs 3.2.0 supports creating the version 5 on-disk format for the XFS file-system. This new XFS format has "significant reliability enhancements" with meta-data CRCs, object back owner references, and better crash recovery reliability. With the upcoming Linux 3.15 kernel this XFS v5 on-disk format is now considered stable / ready for production workloads and lost its experimental marking just with 3.15-rc5." Currently, it is not possible to take advantage of these features when creating a filesystem with Gentoo live media. Note that, by default, mkfs.xfs will not enable these features unless the user specifically requests it. For example: # mkfs.xfs -m crc=1, These new features are very useful and most were introduced in Linux 3.10. The second reason is that the tools are much more reliable. Recently, I had to recover a very large XFS filesystem which had experienced corruption. While the corruption was not especially serious, it was enough to prevent the filesystem from being mountable. In particular, the log could not be replayed. What I discovered was that there was no way to use xfsrepair from xfsprogs-3.1 without running out of memory. In my case, it would always bail out after reaching the 11th allocation group: - agno = 11 xfs_repair: libxfs_initbuf can't memalign 8192 bytes: Cannot allocate memory Ultimately, I compiled a xfsprogs-3.2 statically and ran it from SystemRescueCd. With that, I recovered the filsystem without any issue and was subsequently able to mount it.
Correction: "mkfs.xfs -m crc=1," should read "mkfs.xfs -m crc=1,finobt=1".
arm stable
Stable for HPPA.
amd64 stable
ppc64 stable
ppc stable
Please note that bug 477758 still affects xfsprogs 3.2.1 . Where should I put the updated patches?
alpha stable
x86 stable
sparc stable
ia64 stable. Closing.
This stabilization was handled poorly, and it's largely the upstreams fault. 3.1.10 was the last stable version in the tree before this. 3.1.11 introduced deprecation warnings people should have seen for functionality to be removed in 3.2.1 and higher (note: they removed deprecated funcitonality in the 3.2.1 point release and not 3.2.0 release). People running stable versions skipped all versions with deprecation warnings and found functionality disappearing without explaination or notice. After a discussion with some of the upstream developers, they have no intention of changing this approach and reserve the right to deprecate a feature in a point release and remove it in the next one (as long as there's approximately 12 months between those releases). I can't think of a way this can be improved short of ensuring every release of this gets the full QA testing run and stabilization before the next point release (barring problems).
