Re: Why is there no JFS?
David Schultz wrote: The easy way to fix this is to insert a new dependency for the completion of the allocation. Basically, this would put in a stall barrier that would cause the outstanding I/O to drain before the new I/O was attempted. All other operations behind the one that caused the stall would b held off, which would avoid the starvation deadlock you describe. Most likely, all this would require some minor code to maintain a running tally of virtual vs. real free block count. It really isn't a big deal. You're saying you can fix the problem where allocations can sometimes fail on a busy 99% full filesystem, but on such a filesystem, you're just as likely to hit it when it's 100% full. Kirk's solution is simple and has the advantage of not requiring additional dependency tracking for the common case. No, actually it should work for 100% full, as well, as long as that 100% full is the real disk vs. the real disk, after all pending updates have been applied. In other words, if it would have worked with soft updates turned off, then it will work with soft updates turned on. I agree that it's not that big a deal, but if that's truly the current excuse for not having soft updates on for the root FS, this removes all pretense for that excuse. IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: The easy way to fix this is to insert a new dependency for the completion of the allocation. Basically, this would put in a stall barrier that would cause the outstanding I/O to drain before the new I/O was attempted. All other operations behind the one that caused the stall would b held off, which would avoid the starvation deadlock you describe. Most likely, all this would require some minor code to maintain a running tally of virtual vs. real free block count. It really isn't a big deal. You're saying you can fix the problem where allocations can sometimes fail on a busy 99% full filesystem, but on such a filesystem, you're just as likely to hit it when it's 100% full. Kirk's solution is simple and has the advantage of not requiring additional dependency tracking for the common case. No, actually it should work for 100% full, as well, as long as that 100% full is the real disk vs. the real disk, after all pending updates have been applied. In other words, if it would have worked with soft updates turned off, then it will work with soft updates turned on. My point was that a busy disk that is nearly 100% full will probably experience intermitted ``disk full'' errors anyway, so it suffices to simply deal with cases such as 'rm -rf foo immediately create lots more files', which softupdates does handle in -CURRENT. IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. The original reason was due to the possibility of installworld failing, due to the case described above not being handled particularly well in FreeBSD 4.X. Sysinstall is perfectly happy with creating a root FS with softupdates enabled. If someone wants to bother changing the default for what little difference it might make in installworld/installkernel times, I would support it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
David Schultz wrote: Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: The easy way to fix this is to insert a new dependency for the completion of the allocation. Basically, this would put in a stall barrier that would cause the outstanding I/O to drain before the new I/O was attempted. All other operations behind the one that caused the stall would b held off, which would avoid the starvation deadlock you describe. Most likely, all this would require some minor code to maintain a running tally of virtual vs. real free block count. It really isn't a big deal. You're saying you can fix the problem where allocations can sometimes fail on a busy 99% full filesystem, but on such a filesystem, you're just as likely to hit it when it's 100% full. Kirk's solution is simple and has the advantage of not requiring additional dependency tracking for the common case. No, actually it should work for 100% full, as well, as long as that 100% full is the real disk vs. the real disk, after all pending updates have been applied. In other words, if it would have worked with soft updates turned off, then it will work with soft updates turned on. My point was that a busy disk that is nearly 100% full will probably experience intermitted ``disk full'' errors anyway, so it suffices to simply deal with cases such as 'rm -rf foo immediately create lots more files', which softupdates does handle in -CURRENT. IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. The original reason was due to the possibility of installworld failing, due to the case described above not being handled particularly well in FreeBSD 4.X. Sysinstall is perfectly happy with creating a root FS with softupdates enabled. If someone wants to bother changing the default for what little difference it might make in installworld/installkernel times, I would support it. For what its worth, I think all that's needed is to change line 339 in usr.sbin/sysinstall/label.c: --- label.c Mon Dec 30 21:19:15 2002 +++ label.c.new Thu Feb 13 11:50:44 2003 @@ -336,7 +336,7 @@ strcpy(pi-newfs_data.newfs_ufs.user_options, ); pi-newfs_data.newfs_ufs.acls = FALSE; pi-newfs_data.newfs_ufs.multilabel = FALSE; -pi-newfs_data.newfs_ufs.softupdates = strcmp(mpoint, /); +pi-newfs_data.newfs_ufs.softupdates = TRUE; pi-newfs_data.newfs_ufs.ufs2 = FALSE; return pi; The patch is against the 5.0-R tagged version, but it should still apply to the current version. I think softupdates is still (viewed as) riskier than synchronous writes, at least for large numbers of writes (like installworld) to a filesystem of limited size, so someone is going to inevitably ask if FreeBSD should be loading the bullets as well. Personally, if it's a matter of choosing overall safety or a performance gain for something you really shouldn't be doing to a live machine anyway, I'll take the safe route and option the performance gain. P.S., thanks everyone for the discussion, it was enlightening. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Thus spake Darren Pilgrim [EMAIL PROTECTED]: David Schultz wrote: Thus spake Terry Lambert [EMAIL PROTECTED]: IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. The original reason was due to the possibility of installworld failing, due to the case described above not being handled particularly well in FreeBSD 4.X. Sysinstall is perfectly happy with creating a root FS with softupdates enabled. If someone wants to bother changing the default for what little difference it might make in installworld/installkernel times, I would support it. For what its worth, I think all that's needed is to change line 339 in usr.sbin/sysinstall/label.c: ... I think softupdates is still (viewed as) riskier than synchronous writes, at least for large numbers of writes (like installworld) to a filesystem of limited size, so someone is going to inevitably ask if FreeBSD should be loading the bullets as well. Personally, if it's a matter of choosing overall safety or a performance gain for something you really shouldn't be doing to a live machine anyway, I'll take the safe route and option the performance gain. I've heard that argument, and while I think it has *some* validity in general, I don't buy it for installworld/installkernel in particular. Softupdates guarantees metadata consistency (modulo hardware issues that have been discussed on this list before), but it can reorder writes and delay the amount of time it takes your data to hit the disk. For an installworld, this means that the window during which you have a partially installed world is slightly larger, but installworld takes a while, so the window is already pretty darn big. The whole rationale for doing installworld/installkernel in a particular sequence is that with any luck, you can boot to single-user mode after something goes wrong and finish the job (or revert to the old kernel.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
This thread should be on -questions. As far as safe updating, one can always take a snapshot before installworld and restore from that if something goes awry. thank you, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
David Schultz wrote: Thus spake Terry Lambert [EMAIL PROTECTED]: In other words, if it would have worked with soft updates turned off, then it will work with soft updates turned on. My point was that a busy disk that is nearly 100% full will probably experience intermitted ``disk full'' errors anyway, so it suffices to simply deal with cases such as 'rm -rf foo immediately create lots more files', which softupdates does handle in -CURRENT. I think the problem that was specifically mentioned, with regard to / (after a lot of assumptions) was a file replacement which had to delete an old file and make room for a new one. I do this all the time, by replacing the kernel and all modules, and keeping one behind, e.g. rm x.old; mv x x.old; cp blah x. This fails on a soft updates system because the deletion is not actually done to the point of the space having been recovered, before the copies are started. IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. The original reason was due to the possibility of installworld failing, due to the case described above not being handled particularly well in FreeBSD 4.X. Sysinstall is perfectly happy with creating a root FS with softupdates enabled. If someone wants to bother changing the default for what little difference it might make in installworld/installkernel times, I would support it. Eh. I don't think it's that useful, but sysinstall in any mode other than create the FS in the first place/new install is not really going to have a lot of opportunity to do that bit flip. The most common way I use sysinstall is to NFS mount a CDROM image off some machine, get the sysinstall image that matches the CDROM image, and copy it to /tmp (this is a bitch; the sysinstall image should be made available by itself on distribution CDROMs; as it is, you have to vnconfig, copy a file off it, and vnconfig again, and copy a file off that, to get the sysinstall program). It's about the only way you can upgrade a rackmount machine with a serial console and no floppy or CDROM drive on it (you need a non-serial console to use the Intel PXE crap to netboot). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
David Schultz wrote: I think softupdates is still (viewed as) riskier than synchronous writes, at least for large numbers of writes (like installworld) to a NB: An initial system install is done with async mounts. You can't use async mounts if you use soft updates, because the dependencies for already outstanding pending writes won't be there after a mount -u. Same is true of sync mounts, but install doesn't use that, or try to use mount -u. I've heard that argument, and while I think it has *some* validity in general, I don't buy it for installworld/installkernel in particular. Softupdates guarantees metadata consistency (modulo hardware issues that have been discussed on this list before), but it can reorder writes and delay the amount of time it takes your data to hit the disk. For an installworld, this means that the window during which you have a partially installed world is slightly larger, but installworld takes a while, so the window is already pretty darn big. The whole rationale for doing installworld/installkernel in a particular sequence is that with any luck, you can boot to single-user mode after something goes wrong and finish the job (or revert to the old kernel.) Heh. This is the Lightning is less likely to hit me if I play golf very fast, even though I'm doing it in a thunderstorm argument. It's based on a false understanding of statistics, and it's the same argument Linux FS people used to use, back before they had an FS that ordered metadata writes, to justify not ordering metadata writes (e.g. use async, the failure window is smaller). And we all know that's really bogus. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Why is there no JFS?
The inspiration for this email was from a thread in -questions: Re: fsck takes very long after crash/reset Is anybody currently working on or does there exist a JFS for FreeBSD? I've read in the archives, the discussion about not really needing JFS because of the benefits of softupdates. As well as some talk about BSD / GPL license issues. Is there not a JFS for FreeBSD becuase, Softupdates do the job just fine and nobody has the time or interest to work on this? I'm not running FreeBSD 5.x. So I'm not able to take advantage of the background fsck. Can anybody comment on their success w/ the background fsck? If a JFS were to be ported and/or developed for FreeBSD what should it be based on? XFS, JFS, ReiserFS??? Who would be considered the maintainer for this type of work? --daxbert To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Someone, quite probably Daxbert, once wrote: The inspiration for this email was from a thread in -questions: Re: fsck takes very long after crash/reset Is anybody currently working on or does there exist a JFS for FreeBSD? http://jfs4bsd.sourceforge.net/ Kevin -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
In 045401c2d2db$f9d45c30$[EMAIL PROTECTED], Daxbert [EMAIL PROTECTED] typed: Is anybody currently working on or does there exist a JFS for FreeBSD? To the best of my knowledge, there is no JFS, and nobody is working on one. I've read in the archives, the discussion about not really needing JFS because of the benefits of softupdates. As well as some talk about BSD / GPL license issues. That should have answered most of your questions. Possibly you need the -current and/or -hackers archives as well. Is there not a JFS for FreeBSD becuase, Softupdates do the job just fine and nobody has the time or interest to work on this? Softupdates with a background fsck solve the problem of wanting to come back up quickly after a crash, which is the most common reason people ask for a JFS. I'm not running FreeBSD 5.x. So I'm not able to take advantage of the background fsck. Can anybody comment on their success w/ the background fsck? Someone in the archives indicated that there limited testing things worked fine. I assume Kirk has tested this as well. If a JFS were to be ported and/or developed for FreeBSD what should it be based on? XFS, JFS, ReiserFS??? One with a license that will let it be distributed in the core. That lets out GPL'ed code, and I believe it lets out XFS as well, though I'm not positive on that. Who would be considered the maintainer for this type of work? Whoever did the work, of course. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
One with a license that will let it be distributed in the core. That lets out GPL'ed code, and I believe it lets out XFS as well, though I'm not positive on that. Just FYI, IBM's JFS is GPL'd, IIRC, according 2 the WWW site for JFS. Hah, yay for acronyms. http://www-124.ibm.com/developerworks/oss/jfs/index.html Don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Thus spake Daxbert [EMAIL PROTECTED]: The inspiration for this email was from a thread in -questions: Re: fsck takes very long after crash/reset Is anybody currently working on or does there exist a JFS for FreeBSD? ... Is there not a JFS for FreeBSD becuase, Softupdates do the job just fine and nobody has the time or interest to work on this? Various people have indicated that they might try to implement them, but there really isn't a lot of support for the idea. People already have softupdates, so there's substantially less incentive to support another technology for ensuring metadata consistency. (As Terry will surely point out if I don't, Softupdates and journalling don't solve *exactly* the same set of problems.) I'm not running FreeBSD 5.x. So I'm not able to take advantage of the background fsck. Can anybody comment on their success w/ the background fsck? Problems have been reported for very large (60 GB+) drives, but otherwise it seems to work well. It is only appropriate to use if the reason you need to fsck is a crash or power failure. If a hardware or software bug messes up part of your FS, you need to run a foreground fsck. If a JFS were to be ported and/or developed for FreeBSD what should it be based on? XFS, JFS, ReiserFS??? It would be easier to add journalling to FFS than to port one of the above filesystems, and the licensing would be problematic. It is less problematic for ReiserFS because Hans Reiser is willing to make exceptions to the GPL as long as e.g. Apple can't build OS X on top of FreeBSD and thereby get ReiserFS without sharing the profits with him. But you still have to find someone for whom softupdates isn't good enough who is willing to do the work. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Thus spake Daxbert [EMAIL PROTECTED]: The inspiration for this email was from a thread in -questions: Re: fsck takes very long after crash/reset Is anybody currently working on or does there exist a JFS for FreeBSD? Various people (including myself and Hiten Pandya) have done work to port the GPL'd JFS implementation, but there's one ugly problem -- the GPL. We can make JFS into a kernel module (avoiding the static-link policy of the GPL), but then it can only (legally) be used on non-root filesystems, as the code to read the root filesystem must be statically linked into the kernel. This in itself makes JFS support somewhat pointless. This is the same reason why XFS and ReiserFS haven't been ported -- the GPL prevents us from statically linking the code into the kernel, hence we can't support booting from any XFS/JFS/ResierFS filesystems. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Matthew Emmerton wrote: Thus spake Daxbert [EMAIL PROTECTED]: The inspiration for this email was from a thread in -questions: Re: fsck takes very long after crash/reset Is anybody currently working on or does there exist a JFS for FreeBSD? Various people (including myself and Hiten Pandya) have done work to port the GPL'd JFS implementation, but there's one ugly problem -- the GPL. We can make JFS into a kernel module (avoiding the static-link policy of the GPL), but then it can only (legally) be used on non-root filesystems, as the code to read the root filesystem must be statically linked into the kernel. This in itself makes JFS support somewhat pointless. Not really. A properly laid-out filesystem hierarchy will result in no writes to / (except for installworld/kernel). That removes the problem that journalling addresses, and is probably why softupdates is disabled by default for /. For large, active filesystems, journalling would be a big improvement when you had to run a foreground fsck. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
northern snowfall wrote: Just FYI, IBM's JFS is GPL'd, IIRC, according 2 the WWW site for JFS. Hah, yay for acronyms. And the IBM JFS is actually the OS/2 JFS, not the AIX JFS. -- TRL To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
On Wed, Feb 12, 2003 at 07:40:00PM -0800, Terry Lambert wrote: Darren Pilgrim wrote: Not really. A properly laid-out filesystem hierarchy will result in no writes to / (except for installworld/kernel). That removes the problem that journalling addresses, and is probably why softupdates is disabled by default for /. For large, active filesystems, journalling would be a big improvement when you had to run a foreground fsck. From what I understand, since I use Linux as well, is that EXT3 is really a sort of journalling layer above EXT2, since you can mount EXT3 systems as EXT2 - just without the journalling. Since FreeBSD does have some support for EXT2 already, would it not be a possibility ..shortest road to Rome -- to extend EXT3 functionality into it ? But then I guess the Stallman factor comes into the equation. But I do agree it would be nice to have journalling available somehow. Rebooting an incorrectly shutdown (crashed) Linux FS using EXT3 or Reiser you miss the repairs going on if you blink. There is of course the operational consideration of speed of disk i/o. I have read conflicting reports on reiser as to whether it is significantly slower or faster than EXT2 -- seems to be dependent on number and size of files on the system. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Terry Lambert wrote: Darren Pilgrim wrote: Not really. A properly laid-out filesystem hierarchy will result in no writes to / (except for installworld/kernel). That removes the problem that journalling addresses, and is probably why softupdates is disabled by default for /. For large, active filesystems, journalling would be a big improvement when you had to run a foreground fsck. Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. If that's the problem, then why doesn't sysinstall enable it by default when partitioning for a new install? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Darren Pilgrim wrote: Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. If that's the problem, then why doesn't sysinstall enable it by default when partitioning for a new install? You can certainly change the options in sysinstall to force Softupdates on / In general, there's little to be gained from it -- on most systems, / is essentially a read-only filesystem, with very little metadata changed except for atime. BTW, IIRC you can certainly 'tunefs -n enable /' while in single-user mode. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
On Wed, Feb 12, 2003 at 07:40:00PM -0800, Terry Lambert wrote: Darren Pilgrim wrote: Not really. A properly laid-out filesystem hierarchy will result in no writes to / (except for installworld/kernel). That removes the problem that journalling addresses, and is probably why softupdates is disabled by default for /. For large, active filesystems, journalling would be a big improvement when you had to run a foreground fsck. Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. There's no chicken and egg problem when you're booting off install media or for that matter from single user mode. The problem was that softupdates means you don't get space back from deleted files immediatly so previously / tended to fillup during installworld or installkernel. I know some fixes have been implemented in that area, but I'm not sure if then mean you can always write to the space occupied by unlinked files or just that you have a better chance. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg19142/pgp0.pgp Description: PGP signature
Re: Why is there no JFS?
Thus spake Brooks Davis [EMAIL PROTECTED]: On Wed, Feb 12, 2003 at 07:40:00PM -0800, Terry Lambert wrote: Darren Pilgrim wrote: Not really. A properly laid-out filesystem hierarchy will result in no writes to / (except for installworld/kernel). That removes the problem that journalling addresses, and is probably why softupdates is disabled by default for /. For large, active filesystems, journalling would be a big improvement when you had to run a foreground fsck. Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. There's no chicken and egg problem when you're booting off install media or for that matter from single user mode. The problem was that softupdates means you don't get space back from deleted files immediatly so previously / tended to fillup during installworld or installkernel. I know some fixes have been implemented in that area, but I'm not sure if then mean you can always write to the space occupied by unlinked files or just that you have a better chance. The problem is effectively fixed in 5.0. Basically, when no space can be found, the syncer is accelerated to try to speed up frees. Technically it's possible to run into a livelock, where you keep freeing space and it keeps getting snatched up before you can grab it, so you wait forever. So IIRC, there is a point where it just gives up on finding the space. However, that won't happen with an install, so the free space problem isn't a reason not to use softupdates on the root FS. I think the default hasn't been changed just because nobody has bothered. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Darren Pilgrim wrote: Terry Lambert wrote: Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. If that's the problem, then why doesn't sysinstall enable it by default when partitioning for a new install? Oliver Stone said it was because there's a conspiracy. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. If that's the problem, then why doesn't sysinstall enable it by default when partitioning for a new install? Oliver Stone said it was because there's a conspiracy. it's the downdraft from the black helicopters To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
Michael Sierchio wrote: Darren Pilgrim wrote: Soft updates are disable on / by default because of the chicken and egg problem of runing tunefs on /. If that's the problem, then why doesn't sysinstall enable it by default when partitioning for a new install? You can certainly change the options in sysinstall to force Softupdates on / In general, there's little to be gained from it -- on most systems, / is essentially a read-only filesystem, with very little metadata changed except for atime. BTW, IIRC you can certainly 'tunefs -n enable /' while in single-user mode. If it's mounted read-only, which requires no other mounts, then you can do it. I believe the reason it's not on in sysinstall is that sysinstall tries to mount things async on the initial install, so that doing things like unpacking ports doesn't take forever. If it fails, you can just restart, and having to do that a couple of times is still faster than waiting for ordered metadata. The technical reason that it doesn't do it is that the mount update is not logically an unmount without destroying vnodes(inodes) in core, with a remount with the new options. The main reason for that is that the dependencies go all the way to the buffer cache, and the backing vnode (e.g. the raw device) that's mounted does not necessarily get its buffers flushed. Basically, you'd have to put a little more work into the mount update code. This was discussed a long time ago on -arch, when soft updates first came into FreeBSD, and then again every 18 months or so, ever after. See Kirk's postings on the subject, if you don't want to take mine for it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
David Schultz wrote: There's no chicken and egg problem when you're booting off install media or for that matter from single user mode. The problem was that softupdates means you don't get space back from deleted files immediatly so previously / tended to fillup during installworld or installkernel. I know some fixes have been implemented in that area, but I'm not sure if then mean you can always write to the space occupied by unlinked files or just that you have a better chance. The problem is effectively fixed in 5.0. Basically, when no space can be found, the syncer is accelerated to try to speed up frees. Technically it's possible to run into a livelock, where you keep freeing space and it keeps getting snatched up before you can grab it, so you wait forever. So IIRC, there is a point where it just gives up on finding the space. However, that won't happen with an install, so the free space problem isn't a reason not to use softupdates on the root FS. I think the default hasn't been changed just because nobody has bothered. The easy way to fix this is to insert a new dependency for the completion of the allocation. Basically, this would put in a stall barrier that would cause the outstanding I/O to drain before the new I/O was attempted. All other operations behind the one that caused the stall would b held off, which would avoid the starvation deadlock you describe. Most likely, all this would require some minor code to maintain a running tally of virtual vs. real free block count. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Why is there no JFS?
On Wed, Feb 12, 2003 at 06:41:56PM -0800, Terry Lambert wrote: northern snowfall wrote: Just FYI, IBM's JFS is GPL'd, IIRC, according 2 the WWW site for JFS. Hah, yay for acronyms. And the IBM JFS is actually the OS/2 JFS, not the AIX JFS. Or AIX JFS2 :) (In fact both AIX JFS2 (j2) and JFS/Linux are pretty different from JFS for OS/2 now, both code-wise and due to additions to the ondisk format. Unfortunately the AIX JFS2 group doesn't even publish documentation on their changes so that the Linux driver uses e.g. a different way of storing ACLs.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
