Subject: Re: MFS over ISO-9660 union mounted with no swap space?
To: Mike Cheponis <mac@Wireless.Com>
From: Gandhi woulda smacked you <firstname.lastname@example.org>
Date: 05/14/1999 14:23:07
On Fri, 14 May 1999, Mike Cheponis wrote:
# This seems like a truly minor issue to me.
# It merely means that the abstraction needs to be split at a lower level,
# and the filesystem built on top of that lower abstraction; the only thing
# common is the allocation bit vector.
No. If you split the abstraction at a lower level, there again, you
start running into performance issues.
Please don't make this into a "well throw more cpu power ($$$) at it"
kind of deal.
# Not necessarily; it depends on allocation policy.
# Also, I don't know why everybody who has commented on this issue
# seems to have been thinking that we're still dealing with 300 MB Fujitsu
# eagle drives! Gosh, my buddy just installed a 22 GB IBM IDE disk into
# his linux box last night (costs $421, incidentally.)
"Plenitude of disk space, cpu power or memory (which, incidentally, is
*still* at a premium out of all of them!) are not excuses for shoddy
programming or design, nor license to abuse any or all of them."
# As for fragmentation, unix should have a backround process that auto-defrags.
Lots of luck.
# > Okay, you have a process that has just allocated a huge chunk-o-swap.
# > Now another process wants to allocate some of that filesystem space
# > as a file.
# > Who's going to lose, the one that got the page, or the one that wants
# > the file?
# This is a policy decison, not a technical decision. Limited resources
# force such policy decisions.
You're dodging the question.
# > What if the process that wanted the file had just been told that
# > the space was available?
# This is, once again, merely a resource allocation issue.
No, it's not, it's called a 'race condition', also known a
# >Which is why we have swap files if you really need them.
# Once again, let me shout at the top of my lungs: swap files are bogus!
# (I know, shouting doesn't help...).
So is your proposal, at least for the moment.
Before you think I'm just peeing all over your idea, it's a nice idea.
Your implementation is flawed unless we rework the idea of what a UNIX
filesystem looks like, and I think that's going to be slow in coming.
# > Once we can
# > DEallocate swap, that will actually be a win,
# Which is -exactly- what you do when the process terminates.
# >but if you're going
# >to do that, DynaSwap is a lose (see above), UNLESS you want to have it
# >available as a tunable parameter for a LIVE filesystem, in which case
# >you know what you're doing with your system. If my system runs out
# >of filesystem space because some process snarfs it up for swap space
# >between the time I ran a statfs() call which returns a suitable
# >amount of space left and a write() sequence which fails, I'm going
# >to be justifiably pissed off unless I've set my system up to do this.
# Policy issue, see above.
Bullbleep. Stop dodging the technical question with policy!
Re: inodes <==> data blocks -- go look in the archives.
Microsoft: Living proof that Borg screw Ferengi.