[Top] [All Lists]

Re: superblocks and lilo

To: Linux XFS <linux-xfs@xxxxxxxxxxx>
Subject: Re: superblocks and lilo
From: Derek James Witt <djw@xxxxxxxxxxxxxx>
Date: 26 Mar 2002 07:24:33 -0600
In-reply-to: <20020326155649.C45001@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <1017092300.2173.13.camel@xxxxxxxxxxxxxxxxxxxxxxxx> <1017093184.1748.32.camel@xxxxxxxxxxxxxxxxxxxxxx> <1017096745.2172.18.camel@xxxxxxxxxxxxxxxxxxxxxxxx> <1017114614.1754.6.camel@xxxxxxxxxxxxxxxxxxxxxxxx> <20020326155649.C45001@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Nathan, yeah. I agree.  I have submitted a lilo patch to do just that
(not allowing itself to install onto a XFS partition). But, it seems
there are going to be folks not subscribed to the list that may
unknowingly install lilo in that manner.  
On Mon, 2002-03-25 at 22:56, Nathan Scott wrote:
> hi,
> On Mon, Mar 25, 2002 at 09:50:14PM -0600, Derek James Witt wrote:
> > Hey all.
> > 
> > I'm going through the kernel source for XFS and I'm trying to find out
> > how many superblocks a partition usually has and the maximum it's
> > allowed to have.
> There is one superblock at the head of every allocation group.
> xfs_info/xfs_db/... will show you how many allocation groups a
> filesystem has.  There is one primary superblock, in the first
> AG (at offset zero); and any number of secondary superblocks -
> the number of AGs is a mkfs time option.
> The primary superblock is the one the kernel uses at all times.
> The secondary superblocks are usually only written at mkfs time,
> and are read by xfs_repair when reconstructing the primary SB.
> > So far in xfs_mount.h, I'm seeing that we are allowed
> > two superblocks.  I am proposing that we have two consecutive primary
> > superblocks (duplicates) in use. In other words, mirrored blocks. 
> I'll leave it for others to judge the relative merits of this,
> my first thought is that it seems overly complex when the answer
> should be "don't overwrite the SB in the first place".
> > So, if lilo or any other boot loader comes along and overwrites a part
> > of the first superblock, the mounting code can still get at the 2nd sb.
> I think the operational model here should remain "run xfs_repair"
> once you've blown your foot off... but, just my 2c.
> > But, the problem is that the size of the superblock I've seen varies
> > from 512 bytes to 65535 bytes.  In lilo's sources, we got blocks of size
> > 1024 and sector sizes of 512. Any ideas on what to do on this?
> The XFS superblock fits within 512 bytes.
> cheers.
> -- 
> Nathan
**  Derek J Witt                                              **
*   Email: mailto:djw@xxxxxxxxxxxxxx                           *
*   Home Page: http://www.flinthills.com/~djw/                 *
*** "...and on the eighth day, God met Bill Gates." - Unknown **

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>