Creating a btrfs file system using btrfs-progs-0.20.rc1.20130308git704a08c-1.fc19, and either kernel 3.6.10-4.fc18 or 3.9.0-0.rc3.git0.3.fc19, makes a file system that cannot be mounted by kernel 3.6.10-4.fc18. It can be mounted by kernel 3.8.4. I haven''t tested any other 3.8, or any 3.7 kernels. Is this expected? dmesg reports: [ 300.014764] btrfs: disk space caching is enabled [ 300.024137] BTRFS: couldn''t mount because of unsupported optional features (40). [ 300.034148] btrfs: open_ctree failed Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 28, 2013 at 11:41 PM, Chris Murphy <lists@colorremedies.com> wrote:> Creating a btrfs file system using btrfs-progs-0.20.rc1.20130308git704a08c-1.fc19, and either kernel 3.6.10-4.fc18 or 3.9.0-0.rc3.git0.3.fc19, makes a file system that cannot be mounted by kernel 3.6.10-4.fc18. It can be mounted by kernel 3.8.4. I haven''t tested any other 3.8, or any 3.7 kernels. > > Is this expected? > > dmesg reports: > [ 300.014764] btrfs: disk space caching is enabled > [ 300.024137] BTRFS: couldn''t mount because of unsupported optional features (40). > [ 300.034148] btrfs: open_ctree failedcommit 1a72afaa "btrfs-progs: mkfs support for extended inode refs" unconditionally enables extended irefs (which permits more than 4k links to the same inode). It''s the right default imo, but there probably should have been a mkfs option to disable it. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mar 29, 2013, at 12:04 AM, cwillu <cwillu@cwillu.com> wrote:> On Thu, Mar 28, 2013 at 11:41 PM, Chris Murphy <lists@colorremedies.com> wrote: >> Creating a btrfs file system using btrfs-progs-0.20.rc1.20130308git704a08c-1.fc19, and either kernel 3.6.10-4.fc18 or 3.9.0-0.rc3.git0.3.fc19, makes a file system that cannot be mounted by kernel 3.6.10-4.fc18. It can be mounted by kernel 3.8.4. I haven''t tested any other 3.8, or any 3.7 kernels. >> >> Is this expected? >> >> dmesg reports: >> [ 300.014764] btrfs: disk space caching is enabled >> [ 300.024137] BTRFS: couldn''t mount because of unsupported optional features (40). >> [ 300.034148] btrfs: open_ctree failed > > commit 1a72afaa "btrfs-progs: mkfs support for extended inode refs" > unconditionally enables extended irefs (which permits more than 4k > links to the same inode). It''s the right default imo, but there > probably should have been a mkfs option to disable it.I just tried this with kernel 3.7.9 and it mounts, as does 3.8.5. However, with 3.8.5, if I create a file system: mkfs.btrfs -l 8192 That is not mountable by 3.8.5. I get: [ 252.870733] btrfs: disk space caching is enabled [ 252.870740] btrfs flagging fs with big metadata feature [ 252.874944] btrfs: failed to recover relocation [ 252.885186] btrfs: open_ctree failed That''s definitely not expected. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Murphy wrote:> On Mar 29, 2013, at 12:04 AM, cwillu <cwillu@cwillu.com> wrote: > >> commit 1a72afaa "btrfs-progs: mkfs support for extended inode refs" >> unconditionally enables extended irefs (which permits more than 4k >> links to the same inode). It''s the right default imo, but there >> probably should have been a mkfs option to disable it. > > mkfs.btrfs -l 8192 > > That is not mountable by 3.8.5. I get: > > [ 252.870733] btrfs: disk space caching is enabled > [ 252.870740] btrfs flagging fs with big metadata feature > [ 252.874944] btrfs: failed to recover relocation > [ 252.885186] btrfs: open_ctree failed > > That''s definitely not expected.mkfs.btrfs -l 8192 with kernel 3.9.0 creates a file system mountable by 3.9.0 and only 3.9.0 (so far). And while there''s no error making such a file system with other kernels, they won''t mount the resulting file system. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy <lists@colorremedies.com> wrote:> Chris Murphy wrote: >> On Mar 29, 2013, at 12:04 AM, cwillu <cwillu@cwillu.com> wrote: >> >>> commit 1a72afaa "btrfs-progs: mkfs support for extended inode refs" >>> unconditionally enables extended irefs (which permits more than 4k >>> links to the same inode). It''s the right default imo, but there >>> probably should have been a mkfs option to disable it. >> >> mkfs.btrfs -l 8192 >> >> That is not mountable by 3.8.5. I get: >> >> [ 252.870733] btrfs: disk space caching is enabled >> [ 252.870740] btrfs flagging fs with big metadata feature >> [ 252.874944] btrfs: failed to recover relocation >> [ 252.885186] btrfs: open_ctree failed >> >> That''s definitely not expected. > > mkfs.btrfs -l 8192 with kernel 3.9.0 creates a file system mountable by 3.9.0 and only 3.9.0 (so far). And while there''s no error making such a file system with other kernels, they won''t mount the resulting file system. >I''m seeing something similar. Using the current master branch of btrfs-progs (https://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git, top commit 7854c8b667654502f69e05584729146a06827bc6 "Btrfs-progs: give restore a list roots option"), if I run ''mkfs.btrfs -f /dev/<device>'' on a 3.7.x vintage kernel, the mkfs operation is successful, but I can''t mount the partition. I am successful on a 3.8.x vintage kernel or testing the _rc code for 3.9. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mar 29, 2013, at 9:42 AM, Mitch Harder <mitch.harder@sabayonlinux.org> wrote:> On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy <lists@colorremedies.com> wrote: >> >> mkfs.btrfs -l 8192 with kernel 3.9.0 creates a file system mountable by 3.9.0 and only 3.9.0 (so far). And while there''s no error making such a file system with other kernels, they won''t mount the resulting file system. >> > > I''m seeing something similar. > > Using the current master branch of btrfs-progs > (https://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git, > top commit 7854c8b667654502f69e05584729146a06827bc6 "Btrfs-progs: give > restore a list roots option"), if I run ''mkfs.btrfs -f /dev/<device>'' > on a 3.7.x vintage kernel, the mkfs operation is successful, but I > can''t mount the partition. > > I am successful on a 3.8.x vintage kernel or testing the _rc code for 3.9.If you try a leaf size other than default, it creates the file system but won''t mount it, for any 3.8.x kernel I''ve tried including 3.8.5. Only 3.9.0 kernels are apparently mounting leaf sizes above 4KB, if the fs was created with btrfs-progs-0.20.rc1.20130308git704a08c. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4/3/13, Chris Murphy <lists@colorremedies.com> wrote:> > On Mar 29, 2013, at 9:42 AM, Mitch Harder <mitch.harder@sabayonlinux.org> > wrote: > >> On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy <lists@colorremedies.com> >> wrote: >>> >>> mkfs.btrfs -l 8192 with kernel 3.9.0 creates a file system mountable by >>> 3.9.0 and only 3.9.0 (so far). And while there''s no error making such a >>> file system with other kernels, they won''t mount the resulting file >>> system. >>> >> >> I''m seeing something similar. >> >> Using the current master branch of btrfs-progs >> (https://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git, >> top commit 7854c8b667654502f69e05584729146a06827bc6 "Btrfs-progs: give >> restore a list roots option"), if I run ''mkfs.btrfs -f /dev/<device>'' >> on a 3.7.x vintage kernel, the mkfs operation is successful, but I >> can''t mount the partition. >> >> I am successful on a 3.8.x vintage kernel or testing the _rc code for >> 3.9. > > If you try a leaf size other than default, it creates the file system but > won''t mount it, for any 3.8.x kernel I''ve tried including 3.8.5. Only 3.9.0 > kernels are apparently mounting leaf sizes above 4KB, if the fs was created > with btrfs-progs-0.20.rc1.20130308git704a08c. >I disagree with cwillu regarding the default setting for extended inode refs. While the extended inode refs are a great addition and solve a long standing problem, it appears only the 3.9.0_rc kernel consistently works with extended inode refs. There should be at least a few working kernel versions out there before this becomes the default. Options like this that will make btrfs unmountable on older kernel versions need "buy-in" by the users. There is still the capability to enable extended inode refs with btrfstune. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Apr 4, 2013, at 11:00 AM, Mitch Harder <mitch.harder@sabayonlinux.org> wrote:> > I disagree with cwillu regarding the default setting for extended inode refs. > > While the extended inode refs are a great addition and solve a long > standing problem, it appears only the 3.9.0_rc kernel consistently > works with extended inode refs.And extended inode refs are related to leaf size, in a way that explains a default 4KB leaf size being mountable with older kernels, but volumes created with larger leaf sizes aren''t mountable? Just a yes or no is fine, I probably wouldn''t understand an explanation of the relationship.> > There should be at least a few working kernel versions out there > before this becomes the default. Options like this that will make > btrfs unmountable on older kernel versions need "buy-in" by the users. > > There is still the capability to enable extended inode refs with btrfstune.The behavior, in effect, acts as a change to the on disk format. It won''t make sense to most users that default 4KB leaf sizes are backwards compatible with prior kernels, but 8/16/32KB leaf size is not. It''s likely I don''t know enough about kernel and fs development, but my instinct is that a longterm kernel needs to support a feature before the feature be a default. If the experimental fs card is applicable, I''d still say that this seems close enough to a format change that it should be postponed to a planned point in time when also implementing other features having a similar consequence. Otherwise, people can''t regress to older kernels at all. And while the most common convention by far in btrfs troubleshooting is to go to a newer kernel, finding regressions either in btrfs let alone elsewhere (e.g. video card drivers) is rather significantly inhibited by being unable to mount a btrfs volume. The prospect of a (final release) Fedora 19 created btrfs volume being totally unreadable by anything less than kernel 3.9.0 is a bit eyebrow raising. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 04, 2013 at 12:00:02PM -0500, Mitch Harder wrote:> I disagree with cwillu regarding the default setting for extended inode refs. > > While the extended inode refs are a great addition and solve a long > standing problem, it appears only the 3.9.0_rc kernel consistently > works with extended inode refs. > > There should be at least a few working kernel versions out there > before this becomes the default. Options like this that will make > btrfs unmountable on older kernel versions need "buy-in" by the users. > > There is still the capability to enable extended inode refs with btrfstune.I agree with you. It''s my mistake that I left it enabled by default in mkfs. It''ll be fixed in next integration branch. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html