* syslinux xfs support
@ 2013-10-15 20:33 Christoph Hellwig
2013-10-15 20:54 ` Dave Chinner
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2013-10-15 20:33 UTC (permalink / raw)
To: pcacjr; +Cc: xfs
Hi Paulo,
just wondering what the state of the xfs support for syslinux is? I
talked to Peter at Linuxcon and he thought it's merged, but looking at
the kernel.org tree I can't find the support.
Also when looking over your branches I noticed that you're using a free
sector in the first filesystem block to store the bootloader. If we
want to go down that route we need to make sure to reserve this sector,
otherwise it might get taken up by newly added metadata.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: syslinux xfs support
2013-10-15 20:33 syslinux xfs support Christoph Hellwig
@ 2013-10-15 20:54 ` Dave Chinner
2013-10-16 5:48 ` Chris Murphy
0 siblings, 1 reply; 4+ messages in thread
From: Dave Chinner @ 2013-10-15 20:54 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: pcacjr, xfs
On Tue, Oct 15, 2013 at 01:33:19PM -0700, Christoph Hellwig wrote:
> Hi Paulo,
>
> just wondering what the state of the xfs support for syslinux is? I
> talked to Peter at Linuxcon and he thought it's merged, but looking at
> the kernel.org tree I can't find the support.
>
> Also when looking over your branches I noticed that you're using a free
> sector in the first filesystem block to store the bootloader. If we
> want to go down that route we need to make sure to reserve this sector,
> otherwise it might get taken up by newly added metadata.
It's also worth pointing out that there's no guarantee that there's
a free sector in the first filesystem block. It's only by luck that
there's free sectors on the default config (512 byte sector, 4
sector sized AG headers, 4k filesystem block). If we have <= 2k filesystem
block there are no free "pad" sectors that can be used, 4k sectors
mean no free sectors either, etc.
Much better would be to create a sector sized file and use fiemap to
get the disk address of the block and feed that into the
bootloader. That works for all filesystems without needing to know
anything about the underlying filesystem structures......
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: syslinux xfs support
2013-10-15 20:54 ` Dave Chinner
@ 2013-10-16 5:48 ` Chris Murphy
2013-10-16 10:50 ` Dave Chinner
0 siblings, 1 reply; 4+ messages in thread
From: Chris Murphy @ 2013-10-16 5:48 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, pcacjr, xfs
On Oct 15, 2013, at 2:54 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Oct 15, 2013 at 01:33:19PM -0700, Christoph Hellwig wrote:
>> Hi Paulo,
>>
>> just wondering what the state of the xfs support for syslinux is? I
>> talked to Peter at Linuxcon and he thought it's merged, but looking at
>> the kernel.org tree I can't find the support.
>>
>> Also when looking over your branches I noticed that you're using a free
>> sector in the first filesystem block to store the bootloader. If we
>> want to go down that route we need to make sure to reserve this sector,
>> otherwise it might get taken up by newly added metadata.
>
> It's also worth pointing out that there's no guarantee that there's
> a free sector in the first filesystem block. It's only by luck that
> there's free sectors on the default config (512 byte sector, 4
> sector sized AG headers, 4k filesystem block). If we have <= 2k filesystem
> block there are no free "pad" sectors that can be used, 4k sectors
> mean no free sectors either, etc.
>
> Much better would be to create a sector sized file and use fiemap to
> get the disk address of the block and feed that into the
> bootloader. That works for all filesystems without needing to know
> anything about the underlying filesystem structures……
I'm curious how that would work.
The minimum bit of code for GRUB or extlinux is a lot bigger than 4KB. A basic self-generated GRUB configuration file is 5.6KB; for extlinux a basic one I have is 518 bytes. The minimum code needed to find the configuration file is ~26KB for GRUB's core.img, and ~34KB for extlinux's ldlinux.sys.
So are both of you referring to the < 440 bytes of bootstrap code that goes in either the MBR or VBR, whose job is to find core.img or ldlinux.sys and blindly load them?
Chris Murphy
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: syslinux xfs support
2013-10-16 5:48 ` Chris Murphy
@ 2013-10-16 10:50 ` Dave Chinner
0 siblings, 0 replies; 4+ messages in thread
From: Dave Chinner @ 2013-10-16 10:50 UTC (permalink / raw)
To: Chris Murphy; +Cc: Christoph Hellwig, pcacjr, xfs
On Tue, Oct 15, 2013 at 11:48:49PM -0600, Chris Murphy wrote:
>
> On Oct 15, 2013, at 2:54 PM, Dave Chinner <david@fromorbit.com>
> wrote:
>
> > On Tue, Oct 15, 2013 at 01:33:19PM -0700, Christoph Hellwig
> > wrote:
> >> Hi Paulo,
> >>
> >> just wondering what the state of the xfs support for syslinux
> >> is? I talked to Peter at Linuxcon and he thought it's merged,
> >> but looking at the kernel.org tree I can't find the support.
> >>
> >> Also when looking over your branches I noticed that you're
> >> using a free sector in the first filesystem block to store the
> >> bootloader. If we want to go down that route we need to make
> >> sure to reserve this sector, otherwise it might get taken up by
> >> newly added metadata.
> >
> > It's also worth pointing out that there's no guarantee that
> > there's a free sector in the first filesystem block. It's only
> > by luck that there's free sectors on the default config (512
> > byte sector, 4 sector sized AG headers, 4k filesystem block). If
> > we have <= 2k filesystem block there are no free "pad" sectors
> > that can be used, 4k sectors mean no free sectors either, etc.
> >
> > Much better would be to create a sector sized file and use
> > fiemap to get the disk address of the block and feed that into
> > the bootloader. That works for all filesystems without needing
> > to know anything about the underlying filesystem
> > structures……
>
> I'm curious how that would work.
>
> The minimum bit of code for GRUB or extlinux is a lot bigger than
> 4KB. A basic self-generated GRUB configuration file is 5.6KB; for
> extlinux a basic one I have is 518 bytes. The minimum code needed
> to find the configuration file is ~26KB for GRUB's core.img, and
> ~34KB for extlinux's ldlinux.sys.
Size isn't an issue - fiemap can give you all the blocks that the
file spans if you need to create a sector map for a larger file.
> So are both of you referring to the < 440 bytes of bootstrap code
> that goes in either the MBR or VBR, whose job is to find core.img
> or ldlinux.sys and blindly load them?
I'm refering to what ever you are writing into the pad sectors in
the first filesystem block. I don't know what you are putting there,
but I doubt that is a file that you set up in the filesystem
namespace...
Perhaps you should have a quick look at how LILO prepares the maps
of the files it needs to load? 'strace lilo' is very informative,
and demonstrates exectly how to map files for a boot loader without
needing any knowledge of the layout of the underlying filesytem....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-10-16 10:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-15 20:33 syslinux xfs support Christoph Hellwig
2013-10-15 20:54 ` Dave Chinner
2013-10-16 5:48 ` Chris Murphy
2013-10-16 10:50 ` Dave Chinner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox