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.

				--*greywolf;
--
Microsoft:  Living proof that Borg screw Ferengi.