When you do a large number of save-list / delete-list operations in a year,
does that tend to fragment your overflow space? Obviously this is not a
serious problem so far, but I'm considering a new toolbox that will be
doing a _whale_ of a lot of 'em, and am trying to plan ahead... The overall
pointer-file space usage won't be very great at any one time, but there will
indeed be much traffic.

Platform, etc etc etc --> however, I would imagine system will try &
re-use space, so provided the list is created & deleted, the space
cleared by the delete is likely to be re-used by the next save, so I
don't think fragmentation would be any greater than for any other file.

NB: Using constant list names can help, because then you will simply be
over-writing an existing entry (may reduce need to delete?) ... and
don't forget list can be saved to ANY file, and/or each account can
have own POINTER-FILE


Frank Winans wrote:

"Ross Ferris" wrote
current release D3/linux,
maybe 200,000 lists of about 2,000 item ids
<< each item id average 8 chars long>> per year.
I notice DM,POINTER-FILE, data section is type DP, so maybe that helps the
frag. problem somehow. {P means always use indirect {pointer} items, no
matter what the item length}}

And yes thanks, I might decide to create local POINTER-FILEs.

The simple answer is yes, there will be fragmentation. Each list starts off
as a single frame with additional frames added every time you cross the
frame limit (4K IIRC). Since your lists average 16K (2K * 8 bytes) you'll
generally use 4-5 frames per list. As there are probably other things going
on, the chance that the frames used will be contiguous is pretty slim, so
you'll be taking frames one at a time and releasing them back, one at a
time.

With 200K lists, that's a million frames floating in and out of overflow.
The changes of fragmentation are pretty good.

Mark

"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

And each session too.

Regards,
Grigory

OK - if you are THAT afraid of the fragmentation, why not store the
lists out to the OS? (Linux in this case) --> just did this on our
Linux system and it works as expected (AOK)

Also means that lists can be easily accessed from OUTSIDE D3 ...
provided that isn't a problem, then you have a zer0-fragmentation
solution

I just set up a pointer-file entry in an account that looked like this:

001 QS
002
003 /pointers

Same mechanism should be AOK on D3/NT

Frank Winans wrote:

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Yes. That is correct. The D3/NT spooler works like that, using native
filespace instead of overflow.

For NT, it would look something like:

001 QS
002
003 drive:/foldername (eg. c:/d3Lists)

each list would be an "item" in the folder and take as much space as it take
in File Allocation Blocks.

However, now that I think about it, this may just serve to fragment your
NTFS. But at least there's a system tool to defrag your disk drives.

For anyone not familiar, the QS tells the file save process to save the
contents of this q-pointer. Q-pointers are not generally saved because it's
assumed that the target of the pointer will be.


Mark Brown