> 1) Keep in mind that depending on the filesystem in use, "full" doesn't > necessarily mean out of (normal data) space. It can also mean out of > inodes as well. Additionally, it can be due to an inconsistent > filesystem -- in which case doing an fsck on the affected fs may well fix > the problem.
I am using the default EXT4 FS that Debian stable installed back in the end of November 2011. > 2) User quotas. I've never used them here so I really don't know how > they work, but if you're running them and your user quota is full on a > filesystem... No quota since it is my personal desktop/workstation machine. > 3) Based on the above and the fact that the default PAN_HOME is ~/.pan2/ > in your home dir, I'd suggest checking inode status on /home and/or > fscking it, and/or checking quotes if you're running them. How do I do that manually? I have seen my Debian machines do forced fsck at boot up after too many boot ups once in a while. I think that is by design. > 4) Note that for many bits of pan, symlinks work just fine. In > particular, I've long run my binary instance with article-cache as a > symlink to a dedicated partition (12 gig, with pan's cache size set > accordingly, the default is a paltry 10 MB... back in 0.133 cache size > could only be set by manually editing pan's preferences.xml, but in newer > versions it's in the GUI), and all instances' scorefiles are actually > symlinks to a single common scorefile. > > Thus, you can try symlinking article-cache and the like to some dir on a > different filesystem, and it should "just work", if you don't want to try > to relocate the entire PAN_HOME elsewhere. > > 5) Of course another alternative to symlinks is bind-mounts. You can > accomplish the same thing as the symlink using a bind-mount to remount > part of the filesystem appearing elsewhere on top of article-cache, if > desired. > > 6) I'm not sure how pan actually saves files, but it's possible it writes > a tempfile in the save location, then renames it when the file is > completely downloaded and decoded. If this is the case, then the tempfile > referenced in the error may actually be in your destination dir, not in > PAN_HOME or a tempdir, which means doing the above inode/fsck/quota/etc > checks on it (assuming it's not the same filesystem as /home). This is what I am thinking. Pan saving huge files in /tmp or something to run out of disk space. I have no problems with split files that aren't big. All the big downloads, that failed from alt.binaries.emulators.mame newsgroup a couple nights ago, were over a GB to 1.55 GB: artwork.7z.ERRORS, cabinets.zip.ERRORS, and pcb.zip.ERRORS. It would make sense that /tmp was not big enough (874 MB free right now). I also forgot to mention that these binary posts were yyencoded files. Does Pan use /tmp to decode? Maybe that's the problem and I need to tell it not to use /tmp. -- Quote of the Week: "I have to sit up with a sick ant." --unknown /\___/\ Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site) / /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net | |o o| | E-mail: phi...@earthlink.net/a...@zimage.com \ _ / If crediting, then please kindly use Ant nickname ( ) and AQFL URL/link. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
