Re: [Pan-users] Trying to use 'new' Pan

[Duncan]

Maurice Batey posted on Tue, 16 Apr 2013 16:18:37 +0100 as excerpted:

> Once I can get conformnation that new pan only uses one control
> directory (~/.pan2), I think I can make the  transition for
> bread-and-butter use).

Our posts probably "crossed in the mail", but just in case you hadn't 
seen that one yet, yes, ~/.pan2 it is, unless you set the PAN_HOME var in 
the environment pan inherits telling it to look elsewhere.

> The trickiest bit is makimg sure existing old pan postings I rely on are
> going to still be available in the short term, which is why I was
> interested in the possibility of being able to call up old pan during
> the early use of new pan.


It's worth noting that pan's expiry handling has changed too.  Old-pan 
used to expire posts when the server did, thus the existence of the saved-
messages pseudo-group.  In new-pan, expiry is set per-server.  (It would 
be less confusing if it were set per group, since groups can appear on 
different servers that might not have the same expiry.  I'm actually not 
sure what pan does in that case.  But if you're sure to set all servers 
to the same expiry, no problem.)

Of course that only (directly) controls the headers.  The messages 
themselves are kept in pan's (relatively small 10 MB by default) message 
cache, where they'll be rotated out quite fast with the default settings 
especially if you're doing binaries.  But it's possible to set a multi-
gig cache and no expiry if you like, and I've done just that here for my 
text instance of pan. (As touched on in the other message, I keep 
separate instances for binaries and text, using a wrapper script and the 
PAN_HOME pointer to do so.)  I have archived messages for some groups 
going back years... from my ISP's servers and newsgroups that don't even 
exist any more (that "server" is set to zero connections, thereby 
disabling attempts to connect with it).

Do be aware, however, that the more messages you save, the longer it 
takes pan to startup and the more memory pan uses, as pan loads all the 
overviews into memory and rethreads at each startup.  On an old "spinning 
rust" drive, that can take some time for "cold disk cache" load, 
particularly if the files are fragmented as they often are when 
downloaded due to multiple thread downloading.  SSDs should eliminate 
some of the problem, and periodically backing up the cache partition, 
running mkfs on it, and copying the files back from backup, effectively 
defrags them, speeding up the cold-cache load time again, until enough 
new messages are cached to slow it down again.  (A copy-on-write 
filesystem such as btrfs should eliminate the fragmentation, while one 
such as ext4 that uses extents should decrease it compared to ext3, but 
it'll still happen.  FWIW I continue to run reiserfs here, while waiting 
for btrfs to stabilize...  I tested btrfs last year so know how it works 
in general, but decided it needed quite a bit more stabilization before I 
could trust it for normal use.  And the fragmentation is definitely 
noticable on reiserfs, with a copy from backup to a freshly mkfs-ed 
partition being NOTICEABLY faster.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman