* 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