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

Re: Bug#465737: Can't mount XFS partition on "/"

Sorry, I fat fingered the debian-boot address.
--- Begin Message ---
This is the Postfix program at host postoffice.aconex.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

			The Postfix program

<debian-boot@lists.debian.orgc>: Host or domain name not found. Name service
    error for name=lists.debian.orgc type=A: Host not found
Reporting-MTA: dns; postoffice.aconex.com
X-Postfix-Queue-ID: E404892ED44
X-Postfix-Sender: rfc822; nscott@aconex.com
Arrival-Date: Thu, 28 Feb 2008 15:08:27 +1100 (EST)

Final-Recipient: rfc822; debian-boot@lists.debian.orgc
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; Host or domain name not found. Name service error
    for name=lists.debian.orgc type=A: Host not found
--- Begin Message ---
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

> 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

>  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.



--- End Message ---

--- End Message ---

Reply to: