On Thu, 2008-02-28 at 02:28 +0100, Frans Pop wrote: > > > > > Thanks for the quick reply. > > On Thursday 28 February 2008, Nathan Scott wrote: > > Been discussing this with the SGI guys. The problem is most likely > > to be that current mkfs.xfs enables the "lazy superblock" accounting > > feature, which was supported in kernels since 2.6.23. > > Nice that's a known problem. Did I overlook it in the BTS?
Its only just become known now. :) > > - run mkfs.xfs with the "-l lazy-count=0" option (probably not a > > great option either). > > This works (tested). I think this is probably our best option. > I could even include a test that only includes the option if the > kernel > version is <= 2.6.22. That way it'll automatically deprecate itself > and we > can also clean this up fairly easily later. My hesitation with that approach is that this is an ondisk format flag. People rightly expect that they can move between different kernels and still mount their filesystems. That of course needs to be balanced by the needs of filesystem developers to move people forward enabling new features. > We will also have to do something for the "etch+1/2" installer as that > uses > the D-I Lenny Beta release and will thus use the new XFS to create > filesystems. Is a file system created using mkfs.xfs with "-l > lazy-count=0" > otherwise completely compatible with XFS as used in Etch? > > So with that the test would be: if kernel <= 2.6.22 OR target system = > etch. I think any test based on kernel version isnt really the right approach, since even though the filesystem is created under a particular kernel version, people still have the expectation that they can move backward many kernel versions and still have it work. And people almost always use default mkfs options, so its important to only make mkfs defaults change after alot of opt-in-only time. > Alternatively, is it possible to use a config file for mkfs.xfs to > disable > this default (comparable to /etc/mke2fs.conf)? Thats been discussed, but noones implemented that for XFS to date. > > IMO, best bet is to get upstream to undo this change for another 6 > > months or so. I'll keep pushing for that. I'd rather not patch in > > such a change myself without them doing a release, but if we have > > no other option, we can do that. > > That's only a stay of execution. No not really, in that in 6-12 months time 99% of kernels that people are using will support this feature, and the problem simply wont arise anymore. > IMHO reverting the change now that it's > happened doesn't make much sense. It makes sense, in that the people who are mkfs'ing at the moment are all testing/unstable people (not stable), so its not hit the unwashed masses yet _and_ those people who have used it tend to see the break right away, so have no data on the new filesystems. Upstream have sent out a patch to revert this change for awhile, so as soon as that goes in I'll upload the new version. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
