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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
