Re: Re: Debian BSD.. cool idea
I recall waay back on Feb 01 when Daniel Burrows wrote:
> Cool. As you said, it's not as optimal -- but I don't know just how bad
> it is :) It's either much less or much more resiliant to a crash of apt itself
> (uncommitted changes will be lost, could be good or bad), and may not be that
> much less efficient in time at startup (instead of backing the memory with the
> file, you're backing it with swap, and I think that Apt already iterates through
> the cache once on startup, which is likely to bring most pages into memory (?) )
Yeah. It's debateable. I think the way apt eats memory anyway, it's not
likely to be noticable =). I had the misfortune of installing Debian
Potato on an old Mac Quadra once, with 8 megs of ram...
> You actually don't have to worry about closing the fd; as I recall, the open
> file will retain a reference in the map list for the process (or whatever BSD
> does). Changes to the disk file will be immediately reflected in a normal
> shared map, but APT locks its files so that only one process at a time can
> modify them anyway (more than one can read from them at a time..)
Right... but if you aren't mmap()'ing then you have a problem. Because the
faked mmap needs to be able to commit the changes to disk, and it doesn't
have a reference of where to write the data. I might be able to extract it
from the FdFile object but I haven't tried extensively. Continuing with
my BruteForceUntilSuccess(tm) program, I'm modifying it to not close files
at all and see what happens :^)
BTW, it looks like there was a deeper issue here than mmap(). I must have
been really tired when I first started debugging this. It looks now to be
something with reading chunks at a time from the Debian package lists.
--
I never killed a man that didn't deserve it.
-- Mickey Cohen
Reply to: