Re: FreeBSD Boot Times
On 6/13/12 6:29 PM, Mehmet Erol Sanliturk wrote: On Wed, Jun 13, 2012 at 3:49 PM, Russell Cattelan catte...@thebarn.com mailto:catte...@thebarn.com wrote: On 6/13/12 2:16 AM, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1206130909310.73...@wojtek.tensor.gdynia.pl mailto:alpine.bsf.2.00.1206130909310.73...@wojtek.tensor.gdynia.pl, Wojci ech Puchar writes: One of the major slowdowns is that we do all the device drivers serially synchronously. Yes definitely. I have been looking into how to potentially defer or parallelize device_attach'es. Defer is turning out to be hard enough since each system is has different requirements to reach a state where it can run /sbin/init. I've started with the John Baldwin's multipass work and have a system stops probing/attaching devices and allows the boot to continue on. The remaining passes I'm triggering from userspace once the system is up. This is all very crude at this point and has been an some work just to understand how the kernel startup code all links together. Note systemd looks interesting from from a demand based startup scheme much like apples launchd. (note systemd uses linux process groups so porting it would take some effort) Ideally it would be nice to get to the point where many devices are only attached once there is a demand for it. Say network interfaces for example: attach it once the init scripts need to config it and then hopefully in an async fashion. Unfortunately that will require locking a bit more fine grain than the current Giant lock. -Russell To reduce the boot time , my opinion is as follows : During install or by using a program , generate a Hardware Profile File . By editing it , mark some devices No check ( for example , a network card or PS/2 mouse or key board , is not connected , RS-232 , Firewire , unused SATA ports , unused IDE ports , etc. , then it is not necessary to check them . ) During boot , first read that Hardware Profile File . Only check ports marked as Check . Linux does this by keeping a list of driver id's and corresponding driver modules. The installers can then generate of list of modules to load based on a scan done at install time. FreeBSD is much more into build everything into the kernel vs having a smaller kernel + modules. There really isn't anything limiting a smaller kernel right now. I have a config with just about everything stripped out to do multipass ordering testing and not have a ton of extra probes going on. After completion of boot , the other ports may checked to update Hardware Profile File if it is requested in Hardware Profile File . Later on , assume a new device is attached . Run the Hardware Profile program to regenerate the Hardware Profile File , or by using dmesg , manually add this device into Hardware Profile File . For removable devices , if some USB , etc. ports are not used , they all may be marked as No Check , for example internal USB ports , unused back panel ports . Making usb async would be a big help in terms of boot time it is one of the slowest subsystems to attach. cam already has a thread for drive scanning but unfortunately the boot still waits for it to scan everything before proceeding. One thing I would like to do is release the boot process once the root drive is found and let the rest of drive discovery happen in the background. The problem that then arises is what is the next barrier point? say when mount -a happening? Right now the rc scripts assume everything is probed and attached. What if the rc scripts could say load all drives, notify me when done, get notification, run mount -a. I was thinking anything new would have to take existing scripts and run them normally. But provide a new framework to allow for things to be migrated over. I do not know such a scheme is useful or not , or usable or not . If I were a boot manager program writer , I would try it . To my knowledge which I may be wrong , at present there is no such a facility . yes something could / should be done. So lets keep the discussion going. -Russell Thank you very much . Mehmet Erol Sanliturk signature.asc Description: OpenPGP digital signature
Re: FreeBSD Boot Times
On 6/13/12 2:16 AM, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1206130909310.73...@wojtek.tensor.gdynia.pl, Wojci ech Puchar writes: One of the major slowdowns is that we do all the device drivers serially synchronously. Yes definitely. I have been looking into how to potentially defer or parallelize device_attach'es. Defer is turning out to be hard enough since each system is has different requirements to reach a state where it can run /sbin/init. I've started with the John Baldwin's multipass work and have a system stops probing/attaching devices and allows the boot to continue on. The remaining passes I'm triggering from userspace once the system is up. This is all very crude at this point and has been an some work just to understand how the kernel startup code all links together. Note systemd looks interesting from from a demand based startup scheme much like apples launchd. (note systemd uses linux process groups so porting it would take some effort) Ideally it would be nice to get to the point where many devices are only attached once there is a demand for it. Say network interfaces for example: attach it once the init scripts need to config it and then hopefully in an async fashion. Unfortunately that will require locking a bit more fine grain than the current Giant lock. -Russell signature.asc Description: OpenPGP digital signature
Re: kexec or similar for FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/6/11 6:23 AM, Andriy Gapon wrote: on 24/10/2011 20:55 Russell Cattelan said the following: So it has been a while and a lot of hair pulling but kload is sorta alive and kicking. It can now load the kernel from userspace, copy it over the running kernel and jump the the kernel entry point. I'm still having problems getting through the boot process due to interrupts arriving for unconfigured handlers. Fatal Trap (30) Just in case, is your original kernel running SMP? I'm working on the SMP stuff now. Trying to get the processors in a state where the restart process can complete. For now I removed the panic call in the unknown interrupt case. What I finally figured out was that starting up the system was overwriting the page tables and caused any of AP's still looking at those locations to cause qemu / kvm to reset :-( - -Russell -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65m7gACgkQNRmM+OaGhBjkaQCfS4rfmuKAyyPWyseEYJaHbq+G h1sAnjPgX2E6x7CEcvN11iR3qtJAfdPA =OgIO -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kexec or similar for FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/8/11 4:10 PM, Andriy Gapon wrote: on 08/11/2011 23:14 Russell Cattelan said the following: On 11/6/11 6:23 AM, Andriy Gapon wrote: on 24/10/2011 20:55 Russell Cattelan said the following: So it has been a while and a lot of hair pulling but kload is sorta alive and kicking. It can now load the kernel from userspace, copy it over the running kernel and jump the the kernel entry point. I'm still having problems getting through the boot process due to interrupts arriving for unconfigured handlers. Fatal Trap (30) Just in case, is your original kernel running SMP? I'm working on the SMP stuff now. Trying to get the processors in a state where the restart process can complete. For now I removed the panic call in the unknown interrupt case. What I finally figured out was that starting up the system was overwriting the page tables and caused any of AP's still looking at those locations to cause qemu / kvm to reset :-( Very interesting. You might also find the following information useful in case you haven't implemented that yet: http://www.intel.com/design/pentium/datashts/242016.htm specifically the Appendix B.5. That is something that we are not doing right now, but what I would prefer us doing even for a normal warm reboot. Namely: In order to do a complete system shutdown, followed by a warm restart if necessary, the operating system should return the system to a state similar to that at power-on. This includes disabling the Local APIC interrupts (LINT0/LINT1/Local APIC Timer/Error interrupt) on all processors, disabling the Local APIC on all APs and disabling all interrupts at all the I/O APICs in the system. Ya I have been slowing figuring that out. I have added a simple routine to tear down the ioapic handlers which seems to be doing the right thing. I do not get the unhandled interrupt message now. Sending an IPI cpustop didn't quite do what I expected in that the cpu is not really stop but just pauseed. So what ended up happening was the cpus 1 + were still using the initial page table the from the first boot, cpu 0 has a different page table set up by the kload process. BUT when the boot process / cpu 0 started setting up the page tables again in the same memory cpu 1+ was still referencing for their page tables qemu / kvm would reset and reboot the VM. It took forever with lots of debug prints in both the kernel and qemu to finally put the pieces together. Changing the cpususpend routine to actually halt the cpu has finally allowed the boot process to actually work using kload on a multi cpu qemu vm. Unfortunately it appears that VirtualBox does not handle things the same and now panics when trying to start the AP's. I'm guessing it has to do with exactly what you are saying and that the local APICs need to be shutdown properly. The linux kexec processes that. I believe that this could be a reason for the spurious interrupts that you get. BTW, I am not completely sure, but it seems that we never disable the timer interrupt(s) during shutdown (unlike interrupts for all/most of other devices). You might also find OpenSolaris code interesting in this respect: http://fxr.watson.org/fxr/source/i86pc/io/pcplusmp/apic_common.c?v=OPENSOLARIS#L1160 http://fxr.watson.org/fxr/source/i86pc/os/machdep.c?v=OPENSOLARIS#L191 Ahh good idea ... I've been trying to make sense of the linux apic code to see how to duplicate the functionality but more examples are always helpful. All the best! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6566gACgkQNRmM+OaGhBikggCfZMob4rbk9SQT+YGXksilCmpA ZnIAnjXyEa2uTVhYNP3SHMCpvWBPxCoP =pDTQ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kexec or similar for FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So it has been a while and a lot of hair pulling but kload is sorta alive and kicking. It can now load the kernel from userspace, copy it over the running kernel and jump the the kernel entry point. I'm still having problems getting through the boot process due to interrupts arriving for unconfigured handlers. Fatal Trap (30) If anybody has some experience with acpi and interrupt configuration in general and is willing to help please let me know. - -Russell On 6/16/11 1:32 PM, Russell Cattelan wrote: I have been contacted about possibly implementing a fast reboot mechanism for FreeBSD similar to kexec on Linux. I have just started looking into how this accomplished so I figured a note to freebsd hackers would also be a good place to ask for comments. Has anybody looked at doing something like kexec? Is it the right thing to do for FreeBSD. I'm concerned that the way FreeBSD handles early kernel modules (loaded via the boot loader) vs linux which does everything via initrd is going to be a problem. Thanks for any help on this. -Russell Cattelan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6lpnYACgkQNRmM+OaGhBgPHwCfd3hVJh3FTjFYlG9Jl1f9LkMD 7h8Ani6zJbix9UGooippNKhyEapDPRoQ =r5Sm -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
kexec or similar for FreeBSD
I have been contacted about possibly implementing a fast reboot mechanism for FreeBSD similar to kexec on Linux. I have just started looking into how this accomplished so I figured a note to freebsd hackers would also be a good place to ask for comments. Has anybody looked at doing something like kexec? Is it the right thing to do for FreeBSD. I'm concerned that the way FreeBSD handles early kernel modules (loaded via the boot loader) vs linux which does everything via initrd is going to be a problem. Thanks for any help on this. -Russell Cattelan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kexec or similar for FreeBSD
On 6/16/11 3:06 PM, Gleb Kurtsou wrote: On (16/06/2011 13:32), Russell Cattelan wrote: I have been contacted about possibly implementing a fast reboot mechanism for FreeBSD similar to kexec on Linux. I have just started looking into how this accomplished so I figured a note to freebsd hackers would also be a good place to ask for comments. Has anybody looked at doing something like kexec? I was working on similar project some time ago. First of all you have to leave hardware in known good state for a new kernel. Reseting devices can be generally accomplished by unloading corresponding kernel modules (even if they are compiled in kernel). The biggest problem for me was timers and programmable interrupt controller. I didn't make it work properly, but my goals where much wider than replacing with another FreeBSD kernel. Aim was to restore initial BIOS state as much as possible. What were your goals beyond booting a new kernel? I think getting back to a known BIOS state is kinda required to get a kernel through the boot process. From what I can tell the main goal of kexec is to avoid the process of re-initializing the hardware via BIOS. Is it the right thing to do for FreeBSD. I'm concerned that the way FreeBSD handles early kernel modules (loaded via the boot loader) vs linux which does everything via initrd is going to be a problem. I find loader code easy work with. You could write dummy filesystem implementation for libstand. So that customized loader will load both kernel and modules yet while running FreeBSD. Your reboot procedure wouldn't even use any BIOS io interrupts. Linux boot is a real mess imho. So it is possible to get back to the loader once the kernel is booted? So the running kernel could load the new kernel / modules and then jump back to the loader to start the boot process. Thanks for any help on this. -Russell Cattelan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Console serial speed
On Wed, 2003-07-30 at 21:58, Doug Ambrisko wrote: Russell Cattelan writes: | How does one set the serial speed of the console. | I changed the boot loader speed to 57600 in make.conf | but the kernel seems to chose random speeds each time | it's booted. | Sometimes it's 9600 sometimes it 115200 other times | it's 38400. | | Note this is on 5.x current You might want to check sys/isa/sio.c in function siocngetspeed. I comment out the return (rclk / (16UL * divisor)); on some of my stable boxes. I've seen a few motherboards that result in a messed up console if I don't do it (ie. wrong speed). I changed the return val to be CONSPEED. The machine now boots with the console speed correctly set to 57600 Thanks... suppose a proper fix would be good :-) Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Console serial speed
On Sat, 2003-07-26 at 07:12, Daniel Lang wrote: Hi, Bruce M Simpson wrote on Sat, Jul 26, 2003 at 10:06:36AM +0100: On Fri, Jul 25, 2003 at 01:06:28PM -0500, Russell Cattelan wrote: How does one set the serial speed of the console. Does specifying BOOT_COMCONSOLE_SPEED=57600 not work? No, I've experienced the same problem years ago. The funny thing is, that it worked on some machines, while it didn't on others. I worked around the problem by putting machdep.conspeed=38400 in /etc/sysctl.conf, so the speed is reset to the right speed, once the system is up. Of course this doesn't work for boot2, loader or the kernel itself. These three components seem to set their console speed in some cases arbitrarly. Yes this seems to be the case. No matter how hard I try to convince sio.c to default to 57600 (I even went as far at setting static volatile speed_tcomdefaultrate = CONSPEED; to 57600) so there would be no confusion. I still end up with random console speed each time. The boot loader did pick up the speed from /etc/make.conf and does come up every time at 57600. In my kernel I have the CONSPEED and the BOOT_COMCONSOLE_SPEED in make.conf set accordingly. Anyway its not a big problem for me now any more, so I never filed a PR. Best regards, Daniel -- Russell Cattelan [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Console serial speed
How does one set the serial speed of the console. I changed the boot loader speed to 57600 in make.conf but the kernel seems to chose random speeds each time it's booted. Sometimes it's 9600 sometimes it 115200 other times it's 38400. Note this is on 5.x current Russell Cattelan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD XFS Port BSD VFS Rewrite
"Alton, Matthew" wrote: Hmm interesting... Guess I need to read the hackers list more often. So anybody interested in what is going on right now? Legal BS; The encumbrance work is progressing at an expected snails pace. The hardest question to answer at this point; What is encumbered and what isn't! It isn't even clear what constitutes encumbrance structures function names/api's. Short summary to all this nobody has any clear idea as to how long before the code can be released. I do have a bit of good news: if anybody is truly interested in helping out with the project they can sign an NDA through the company that sgi has contracted to work on the linux port. This is basically to protect SGI until the code has be officially clean and blessed. Contact me directly if you are interested [EMAIL PROTECTED] Where are we at with the linux port... Well we can mount file systems, df, ls, and read files (not a complete implementation) I am currently working on the write path, this one is much more complicated and will require addition work from other people to complete first. There are a lot and I mean a lot of issues involved with getting xfs to interface with the buffer/memory management system of an OS. IRIX pulls a lot of tricks with delayed allocation, holes, overlapping buffers, pining etc. etc. There is a lot of discussion amongst the linux people about how to proceed with upgrading linux's buffer/page code. I am currently trying to keep linux specific stuff out of the bowels of XFS. In fact one of our main goals is change a little XFS code as possible since all current improvements / bug fixes are being done on the IRIX code base. If people have ideas how how to keep this a "portable" file system let me know. It is easier for me to push things in certain directions now rather than later. I spent an hour on the phone with SGI's lead FS scientist Dan Koren discussing the XFS situation, Margot Seltzer's LFS work, ships, sails, sealing wax... The code is not yet open. It is being "disencumbered" and retrofitted to the Linux kernel interfaces by a team of contractors and university people all under NDA. So we're on hold for the time being. Unless you want to sign an NDA and move to Iowa for a year or so. We BSDies really are going to have to come up with something in the way of a modern storage subsystem. -Original Message- From: Andrzej Bialecki [SMTP:[EMAIL PROTECTED]] Sent: Saturday, October 30, 1999 10:56 AM To: Alton, Matthew Subject: Re: BSD XFS Port BSD VFS Rewrite On Thu, 5 Aug 1999, Alton, Matthew wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon Is there anything that you might say on the progress status of this project? Thanks! Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Glad to hear somebody is willing to dive in to XFS. Right now I am one of three people working on the XFS to linux port, so I have pretty good view of what is currently happening. When is it going to be ready? Don't hold your breath. Officially SGI has said by the end of the year, technically... whew frankly I can't even guess. I would hope within a month or so we will have the basics of a FS. There are a lot of hurtles to overcome. XFS is a very very complex file system that relies on some of the more advanced features of IRIX. The buffer cache and chunk cache (chunking buffers together to do large IO) are two examples that come to mind. SGI is rewriting the buffer cache (calling it the page cache) such that is will be able to support XFS. chunk cache... ? not sure what we are going to do with that. We have been having several discussions about the best way to "interface". IRIX uses VFS,VNODE,BEHAVIOR which is similar to the BSD's interface but of course very IRIX specific. Linux's vfs/vnode is different from either. Realizing this, a lot of our discussions have been around how to go at making a new/modify existing interface layer that might be more "universal" i.e. not irix not linux not bsd not etc specific. In reading Terry's Bill's comments seems there is a a lot of room for improvement. Initially we trying to make as few changes as possible to XFS to get an initial implementation running on linux. After we get things running we will start to analyze where the problems exist, and decide what direction in terms of interface to take at that time. I would like any constructive input people have on this matter. I have a pretty good chance of setting design direction. Be waned: SGI at the moment is committed to linux, development directions will favor that platform. They are not against other OS's being XFS'atized but SGI is in the business of selling hardware/solutions based on that hardware and linux one of the OS they have decided to use for their intel based boxes. Also as far as the GPL issue goes, get over it! I understand the issues and agree with many of the points. My suggestion lets find a way to work with the GPL (i.e. loadable kernel module / softupdates model) If somebody has a very very good argument/solution to the licensing debate let me know, I can present it to the people dealing with the lawyers. The license issue has slowed the release of the actual code more than anything else, and will not be revisited again without great pain. I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of "The Design and Implementation of the 4.4BSD Operating System" still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD-XFS Update
"Alton, Matthew" wrote: SGI has released a portion of the XFS source code under the GPL: http://oss.sgi.com/projects/xfs/download/ the source file is xfs_log.tar.gz. Of greater interest at this stage are the documents in: http://oss.sgi.com/projects/xfs/design_docs/ I am currently researching methods for implementing the 64-bit syscalls stat64(), fstat64(), lseek64() etc. delineated in the SGI design doc _64 Bit File Access_ by Adam Sweeney. The 64 calls are no longer an issue as of IRIX 6.(something 2 I think) all the standard calls were converted to use 64 bit types directly. Have a better one for you to research. Find out if buffers can be pined? if not what is it going to take to fix that. The BSD-XFS port will be made available as a patch to the RELEASE FreeBSD kernels. Given the size of XFS it might be easier to make FreeBSD a patch to XFS. - major humor here. :-) :-) Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD-XFS Update
Alton, Matthew wrote: SGI has released a portion of the XFS source code under the GPL: http://oss.sgi.com/projects/xfs/download/ the source file is xfs_log.tar.gz. Of greater interest at this stage are the documents in: http://oss.sgi.com/projects/xfs/design_docs/ I am currently researching methods for implementing the 64-bit syscalls stat64(), fstat64(), lseek64() etc. delineated in the SGI design doc _64 Bit File Access_ by Adam Sweeney. The 64 calls are no longer an issue as of IRIX 6.(something 2 I think) all the standard calls were converted to use 64 bit types directly. Have a better one for you to research. Find out if buffers can be pined? if not what is it going to take to fix that. The BSD-XFS port will be made available as a patch to the RELEASE FreeBSD kernels. Given the size of XFS it might be easier to make FreeBSD a patch to XFS. - major humor here. :-) :-) Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.al...@anheuser-busch.com al...@plantnet.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Russell Cattelan catte...@thebarn.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Glad to hear somebody is willing to dive in to XFS. Right now I am one of three people working on the XFS to linux port, so I have pretty good view of what is currently happening. When is it going to be ready? Don't hold your breath. Officially SGI has said by the end of the year, technically... whew frankly I can't even guess. I would hope within a month or so we will have the basics of a FS. There are a lot of hurtles to overcome. XFS is a very very complex file system that relies on some of the more advanced features of IRIX. The buffer cache and chunk cache (chunking buffers together to do large IO) are two examples that come to mind. SGI is rewriting the buffer cache (calling it the page cache) such that is will be able to support XFS. chunk cache... ? not sure what we are going to do with that. We have been having several discussions about the best way to interface. IRIX uses VFS,VNODE,BEHAVIOR which is similar to the BSD's interface but of course very IRIX specific. Linux's vfs/vnode is different from either. Realizing this, a lot of our discussions have been around how to go at making a new/modify existing interface layer that might be more universal i.e. not irix not linux not bsd not etc specific. In reading Terry's Bill's comments seems there is a a lot of room for improvement. Initially we trying to make as few changes as possible to XFS to get an initial implementation running on linux. After we get things running we will start to analyze where the problems exist, and decide what direction in terms of interface to take at that time. I would like any constructive input people have on this matter. I have a pretty good chance of setting design direction. Be waned: SGI at the moment is committed to linux, development directions will favor that platform. They are not against other OS's being XFS'atized but SGI is in the business of selling hardware/solutions based on that hardware and linux one of the OS they have decided to use for their intel based boxes. Also as far as the GPL issue goes, get over it! I understand the issues and agree with many of the points. My suggestion lets find a way to work with the GPL (i.e. loadable kernel module / softupdates model) If somebody has a very very good argument/solution to the licensing debate let me know, I can present it to the people dealing with the lawyers. The license issue has slowed the release of the actual code more than anything else, and will not be revisited again without great pain. I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? -- Russell Cattelan catte...@thebarn.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
