上記の変更で、freebsd-stable ML に下記のようなやりとりがあったので RELENG_4_6 もだなと思ったのですが… 今のところ変化なしですね ^^;
>> I've just committed a fix for the tags problem, so please those >> that had this problem, test it out and let me know... > > I think it must be committed to RELENG_4_6. Codebase is the same, > bugfix is clear, usefullness is clear. ;))
I second the motion, although if any other fixes are immediately pending it would be prudent to commit them to RELENG_4 for a bit of exposure and then do a single "ata patch" commit to RELENG_4_6.
This commit adds basic support for the UFS2 filesystem. The UFS2 filesystem expands the inode to 256 bytes to make space for 64-bit block pointers. It also adds a file-creation time field, an ability to use jumbo blocks per inode to allow extent like pointer density, and space for extended attributes (up to twice the filesystem block size worth of attributes, e.g., on a 16K filesystem, there is space for 32K of attributes). UFS2 fully supports and runs existing UFS1 filesystems. New filesystems built using newfs can be built in either UFS1 or UFS2 format using the -O option. In this commit UFS1 is the default format, so if you want to build UFS2 format filesystems, you must specify -O 2. This default will be changed to UFS2 when UFS2 proves itself to be stable. In this commit the boot code for reading UFS2 filesystems is not compiled (see /sys/boot/common/ufsread.c) as there is insufficient space in the boot block. Once the size of the boot block is increased, this code can be defined.
7月17日ごろに4.6.1-RELEASEがでるそうな。 --- The release engineers, port managers, and security officer team are currently working on a conservative set of changes to merge to the RELENG_4_6 branch in preparation for a 4.6.1 release. This point release will include Soren's one-line ATA patch that fixes some of the reported ATA problems, along with security-related updates for SSH, BIND, ktrace, and possibly sendmail. 4.6.1 is currently scheduled for July 17. If you have any questions or comments about this point release, please let us (re@) know. Thanks!
Unfortunately the release of 4.6.1 has been delayed for various reasons including very recently discovered vulnerabilities. The release engineers do not wish to roll a release that includes known security flaws. We are also still waiting on a few serious bug fixes to be merged into the RELENG_4_6 branch. Since the RELENG_4_6 branch already has a tag for 4.6.1 and since the branch has had the name 4.6.1-RELEASE for over a week already, the security-officer and release engineering teams feel that it would be less confusing to rename the pending release to 4.6.2. Unfortunately, a few things were done prematurely in the handling of 4.6.1, and we have learned from that mistake.