On Wed, Nov 03, 1999 at 05:40:03PM -0600, Tim Mooney 
<[EMAIL PROTECTED]> wrote:
> As far as I know, most Unix and Unix-like OSes will generally try give you
> the space you're requesting as a contiguous chunk.  In the case of files like
> a (e.g.) 40 Meg swap-file for the gimp, that may not be possible, even for
> a filesystem that is much less than 50% full.  All it takes is "average"
> fragmentation to ruin the OS' ability to give you a contiguous chunk.

Then you have to convince me (you don't have, but I won't believe you)
that this is a problem... surely, each ~8MB chunk of a large file is
fragmented on an ext2 file system _by definition_, but these are very
large chunks.

> This means, I think, that all bets *are* off, at least regarding the gimp's
> ability to keep tiles "close" on-disk.

I think that on an OS that encourages fragmentation you are
right. However, I can't think of a common os in use that allows to run
gimp and has such a bad filesystem.

> The bigger the swap file, the less likely it is that the gimp will be
> able to do this.  That's why I asked my original question.

But this is not at all a problem. For example, on my 8GB main (i.e. /usr,
/home) partition that I already use since two years ans that is 95% full
(too full for the file system in question) I have 0.5% fragmentation. Only
two files have fragmented chunks smaller than 8MB (the maximum).

In any case, since you think this is bad (and I think this is good), only
hard data would clear this problem.

However, as a matter of fact, linux' swapping (the os with the ext2 fs) is
_far_ worse than _any_ application-side swapping.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Reply via email to