Return to troubleshooting.doc CVS log

Up to [GPL Stacker compression] / dmsdos / doc

Annotation of dmsdos/doc/troubleshooting.doc, revision 1.1

1.1     ! root        1: troubleshooting.doc
        !             2: 
        !             3: This file contains solutions to common problems with the dmsdos driver.
        !             4: It is mostly based on the feedback of dmsdos users that have sent mail to me
        !             5: for some hints (thanks a lot to all of you!).
        !             6: 
        !             7: ------------------------------------------------------------------------------
        !             8: 
        !             9:   If you have problems, you may have found a bug. But check the following
        !            10:   list before (it is a collection of problems I have been reported and, I
        !            11:   think, can be solved easily). See also file BUGS for a list of known bugs.
        !            12: 
        !            13:   *** See also your kernel log for 'DMSDOS:...' messages. Each message is
        !            14:       explained in file messages.doc. There you can find hints how to
        !            15:       solve the problems, too.
        !            16: 
        !            17: - It does not install/compile!
        !            18: 
        !            19:   Maybe the cvf.diff did not apply correctly. Check for *.rej files in
        !            20:   your kernel sources (only for the 2.0.xx kernels).
        !            21:   
        !            22:   In some 2.1.xx kernels umsdos is broken. Get at least 2.1.94 if you want
        !            23:   to use umsdos together with dmsdos.
        !            24: 
        !            25:   Depending on the dmsdos configuration the code might fail to compile.
        !            26:   Critical configuration options are:
        !            27: 
        !            28:      * advanced memory management (switch it off if problems occur)
        !            29:      * writable mmap (switch it *on* for latest 2.1.xx kernels)
        !            30: 
        !            31:   Please keep in mind that 2.1.xx kernels are still changing quite fast.
        !            32:   I cannot test every configuration option against each kernel...
        !            33: 
        !            34: - The module doesn't load. It fails with a message about undefined symbols.
        !            35: 
        !            36:   The dmsdos module requires fat filesystem support. If the fat module is
        !            37:   not loaded and not part of the kernel the dmsdos module refuses to load
        !            38:   and complains about missing symbols. Since kernel 2.0.34, fat additionally
        !            39:   depends on nls support. If it is the UMSDOS module that doesn't load, 
        !            40:   see also the next problem :)
        !            41: 
        !            42: - The UMSDOS module doesn't load though fat and msdos support is present.
        !            43:   It complains about missing symbols 'fat_readpage' and 'fat_dir_ioctl'.
        !            44: 
        !            45:   This is a known bug in some older cvf.diffs from alpha test versions.
        !            46:   I forgot to add some symbols to the export list in older cvf.diffs for
        !            47:   kernel 2.0.33. This bug also went in 2.1.80 when CVF-FAT was included.
        !            48:   In order to fix the problem, edit file linux/fs/fat/fatfs_syms.c and
        !            49:   append the missing symbols 'fat_readpage' and 'fat_dir_ioctl' to the
        !            50:   export list. Look how the other symbols are listed there and put in the
        !            51:   missing ones in the same way. Then recompile the fat module (or the
        !            52:   kernel if your fat support isn't modular).
        !            53: 
        !            54: - It crashes and writes a register dump to the syslog.
        !            55: 
        !            56:   If you did not load the module with the -m flag this time, you are out 
        !            57:   of luck here. Please load the module with the -m flag (this prints a 
        !            58:   symbol table) and redirect the output into a file. This symbol table is 
        !            59:   required to analyse the crash. The symbol table usually differs from one 
        !            60:   insmod to another depending on free memory pages, so you cannot just
        !            61:   use an older one :) Then try to reproduce the problem.
        !            62: 
        !            63:   This smells like a bug - most likely. To be sure that this is really a
        !            64:   dmsdos related problem please read the README file in the Linux kernel
        !            65:   sources (/usr/src/linux/README). There's a procedure explained how to
        !            66:   obtain valuable information from the register dump in the syslog, in
        !            67:   particular, how to find out in which function the crash occured. Please
        !            68:   note that the register dump is absolutely system dependent and thus must 
        !            69:   be analysed and interpreted by *you* (it's really not difficult, but it must
        !            70:   be done carefully - otherwise it's meaningless). Just use the symbol table
        !            71:   the insmod -m command created *before* the crash.
        !            72: 
        !            73:   If it turns out to be a dmsdos function, you have discovered a serious bug 
        !            74:   that should be fixed. Please send a bug report in that case. Please also
        !            75:   explain how to reproduce the problem with simple commands like 'ls',
        !            76:   'cat' or 'touch', for example.
        !            77: 
        !            78: - It hangs without any comments.
        !            79: 
        !            80:   Can you switch to another virtual console and enter commands there? What 
        !            81:   does 'ps' tell about the hanging process? Can you kill it? If the answer
        !            82:   to all these is no, this may be a bug.
        !            83: 
        !            84:   Can you reproduce the problem with simple commands like 'ls' or 'cat'?
        !            85: 
        !            86:   Please note that write access to a compressed partition may be awfully
        !            87:   slow. This depends on the compression level and on the fragmentation of
        !            88:   the compressed filesystem. Such a situation might be interpreted as a hang
        !            89:   though it isn't really one (especially on a 386SX16 machine...).
        !            90: 
        !            91:   Also reading a large file or a huge directory might cause a system freeze 
        !            92:   for a short time. This is especially true for the /dev directory (given
        !            93:   that you copied it to a compressed partition...)
        !            94: 
        !            95: - After mounting the CVF I only see garbage when I do 'ls /_mountpoint_'.
        !            96: 
        !            97:   Are you sure you loaded the dmsdos module? The plain fat driver (without
        !            98:   the dmsdos module) mounts some compressed volumes without complaining, but
        !            99:   it really can't deal with them and logs a lot of errors when trying to
        !           100:   read, for example, a directory on that partition. Since the mount command
        !           101:   is exactly the same this might indeed happen accidentially.
        !           102: 
        !           103:   Take a look at your system log (usually in /var/log/messages). If you
        !           104:   don't see DMSDOS messages - unmount the filesystem, load the dmsdos module
        !           105:   and try again.
        !           106: 
        !           107:   If you are sure you have loaded the module (try 'lsmod') dmsdos auto
        !           108:   detection may have failed. Try again with the appropriate cvf_format=xxx
        !           109:   mount option, i.e. cvf_format=dblspace (for M$ doublespace and drivespace)
        !           110:   or cvf_format=stacker (for Stacker 3 and 4).
        !           111: 
        !           112:   If you do see DMSDOS messages, there are very likely much of them. If
        !           113:   the dmsdos driver cannot deal correctly with a filesystem it becomes
        !           114:   very noisy and sets the partition to read-only mode. In that case, please
        !           115:   let me know. You might have a new dblspace or stacker version that
        !           116:   should be supported too.
        !           117: 
        !           118: - I cannot write to files, delete files, create directories ... in the
        !           119:   compressed subdirectories.
        !           120: 
        !           121:   Lots of possibilities here -- watch your kernel log for a DMSDOS error
        !           122:   message that may explain what went wrong...
        !           123:   * Have you disabled write access at compile time? Then you'll find a
        !           124:     "write access not compiled in" message.
        !           125:   * Did you mount read-only (option ro)?
        !           126:   * Is your compressed partition almost full? The driver refuses to allocate
        !           127:     new clusters on a partition that is almost full when it thinks further
        !           128:     write access may be dangerous and might cause data loss. Delete some
        !           129:     files and retry.
        !           130:   * The compressed partition may have errors. The driver sets errorneous
        !           131:     compressed partitions to read-only immediately after mounting them. 
        !           132:     However, you can allow write access again by setting the comp parameter
        !           133:     via dutil (example: 'dutil /DOS/dblspace.001 setcomp guess'). Of course,
        !           134:     it is not recommended to write to errorneous partitions.....
        !           135: 
        !           136: - When trying to write to a compressed filesystem I receive I/O errors.
        !           137: 
        !           138:   See previous problem. If you think it's another reason, run dutil to check 
        !           139:   whether the filesystem is full or too fragmented. If the compressed
        !           140:   filesystem is read-only, all write access to the compressed filesystem is 
        !           141:   refused. There is, of course, no real I/O error. The dmsdos driver returns 
        !           142:   the 'permission denied' or 'no space left on device' error code depending 
        !           143:   on the situation, but some applications simply claim 'I/O error' instead.
        !           144: 
        !           145: - When trying to write to the compressed partition, I receive "no space left
        !           146:   on device" errors though dutil says there's *a lot* of free space (>100KB).
        !           147: 
        !           148:   That depends. 100KB is not much. If the filesystem does not allow
        !           149:   fragmented data dmsdos reserves the space of 10 clusters for the case of
        !           150:   emergency (just imagine that data that compress well can be replaced by 
        !           151:   data that don't compress at all and need more physical space). For a CVF 
        !           152:   with 8KB cluster size it's 80KB, for a CVF with 32KB cluster size it's 
        !           153:   320KB. You cannot use this space for regular data. If the filesystem 
        !           154:   supports fragmented data (e.g. drivespace 3, stacker 4) it's enough to 
        !           155:   reserve space for one fragment of maximum size (drivespace 3: 32.5KB, 
        !           156:   stacker 4: fragment support for write access is not yet implemented, 
        !           157:   so size is 10 clusters).
        !           158: 
        !           159:   There are some other possibilities. You may have run out of clusters. The
        !           160:   driver ensures that you don't get more clusters than dos would give to
        !           161:   you (otherwise dos' scandisk.exe would *destroy* the compressed partition
        !           162:   the next time it checks it by inventing some strange errors and trying to
        !           163:   correct them [arghhhh... seems to be a scandisk bug]). This can be fixed
        !           164:   by booting dos, running dblspace.exe or drvspace.exe, and setting the 
        !           165:   compression ratio to the value the program suggests. (The procedure for
        !           166:   Stacker should be similar.) Don't be surprised if it suggests high
        !           167:   compression rates you aren't used to from dos - it's because dmsdos
        !           168:   compresses a little better than dos itself. (In fact, you needn't
        !           169:   believe the value dos claims - it's exaggerating sometimes....)
        !           170: 
        !           171:   The third possibility is that your compressed partitiion has become too
        !           172:   fragmented at internal MDFAT level. Dos 6.0-6.22 Doublespace/Drivespace
        !           173:   and Win95 Doublespace/Drivespace (*not* drivespace 3) and Stacker 3 are
        !           174:   known to suffer extremely from internal MDFAT level fragmentation. Note
        !           175:   that this kind of fragmentation is different from usual FAT level
        !           176:   fragmentation and can not be repaired by those popular FAT defragmentation 
        !           177:   programs. Use the CVF maintainance tools that came with your CVF software
        !           178:   to defragment the CVF.
        !           179: 
        !           180: - A file I want to read appears to be empty but the directory says it is not
        !           181:   empty.
        !           182: 
        !           183:   There was a problem decompressing the file. See your kernel messages
        !           184:   (/var/log/messages). The first thing to do is to boot dos and run the dos
        !           185:   filesystem checker on the compressed partition (do not skip the surface test
        !           186:   since only this test finds erros in compressed data). After that, reboot
        !           187:   Linux and retry. If the problem did not disappear this may be a real
        !           188:   dmsdos bug and should be emailed to the author.
        !           189: 
        !           190: - I mounted a compressed floppy at /mnt as type umsdos and tried to run 
        !           191:   umssync on the disk. It failed with an error message and now some or all 
        !           192:   files are gone (help)!
        !           193: 
        !           194:   You cannot umssync a compressed floppy without freeing up some space for
        !           195:   the umsdos special file --linux-.--- (the real msdos part of a compressed
        !           196:   floppy is always totally full).
        !           197: 
        !           198:   But you have luck, the files are not gone at all. Unmount the floppy and 
        !           199:   mount it as type msdos. Then remove the (empty) file --linux-.--- and the
        !           200:   'readme' or 'readthis' or whatoever (it contains a message that this disk
        !           201:   is compressed and that you must run Micro$ doublespace to read it ...
        !           202:   very interesting - and not true at all: you can use Linux and dmsdos
        !           203:   instead :-) ). Now there should be some bytes free for umsdos. Unmount
        !           204:   the floppy again, mount it as type umsdos and retry. If the problem
        !           205:   appeared inside the compressed partition, also mount as type msdos, remove
        !           206:   --linux-.--- where files were gone, free up some space, mount again as type 
        !           207:   umsdos, and retry running umssync.
        !           208: 
        !           209:   This problem might be considered a umsdos caveat.
        !           210: 
        !           211: - The utility dutil reports a different compression ratio and different free
        !           212:   space than dos.
        !           213: 
        !           214:   The utility uses another method to calculate the compression ratio and the
        !           215:   amount of free space. Well, dos displays a dream ratio, dutil exactly
        !           216:   determines how much the files shrunk on compression. Dos' ratio is higher
        !           217:   because it compares the space the files *have* allocated with the space
        !           218:   the files *would have* allocated on an uncompressed partition with an 8 KB
        !           219:   (32KB under drivespace 3) cluster size. The slack at the end of the files
        !           220:   causes the difference (especially on small files), but saving wasted space
        !           221:   is not the same as compression (I think). Since the ratio is used to
        !           222:   estimate the free space, this value is also different.
        !           223: 
        !           224: - The external utility dutil displays garbage.
        !           225: 
        !           226:   You may have an old version of dutil somewhere in
        !           227:   your path, find and delete it and recompile dutil. If dutil displays just
        !           228:   zeros, you are definitely running a dutil from an older dmsdos version. 
        !           229:   Remove it and recompile the source.
        !           230: 
        !           231: - The external dmsdos utility displays some "lost clusters", but dos'
        !           232:   scandisk says everything is okay.
        !           233: 
        !           234:   The term "lost clusters" doesn't mean that the clusters are not assigned to
        !           235:   a file (like in a normal dos fs). Instead, it tells there are clusters that
        !           236:   have been allocated in the FAT but have a zero MDFAT entry. This is not a
        !           237:   filesystem error, it only means that the clusters do exist, but they don't
        !           238:   contain any data and therefore don't use disk space. So they aren't really
        !           239:   used, but they aren't free either. This is a special situation that can only
        !           240:   occur in a compressed filesystem. 
        !           241: 
        !           242: - I can't see long filenames on my win95 partitions, I only see the short
        !           243:   ones.
        !           244: 
        !           245:   Mount as type vfat instead of msdos.
        !           246: 
        !           247: - I cannot unmount my dmsdos partition. umount complains with "device busy".
        !           248: 
        !           249:   Some process is currently using a file or a directory of your partition.
        !           250:   Find and kill it, then retry. This may be the external dmsdos daemon...
        !           251:   Hint: 'man fuser'.
        !           252: 
        !           253: - I cannot read some directories in my CVF. They seem to be empty, but they
        !           254:   aren't empty under dos/win95.
        !           255: 
        !           256:   Watch for DMSDOS error messages in the kernel log.
        !           257: 
        !           258: - On mount, I receive some strange error messages saying there were errors
        !           259:   in cluster xyz, but dos scandisk doesn't find them and even tells that the 
        !           260:   CVF doesn't have such many clusters.
        !           261: 
        !           262:   Sorry, there *is* an error in your filesystem. However, it's a kind of
        !           263:   hidden error, i.e. it doesn't have an immediate effect. It's due to
        !           264:   garbage in some currently unused parts of the FAT or MDFAT. Most likely
        !           265:   the slack of the FAT or MDFAT is not zerod out. It should be zerod out
        !           266:   in order to represent still a valid FAT/MDFAT in case the compressed
        !           267:   filesystem is enlarged (this may even happen by increasing the compression
        !           268:   ratio). Dos scandisk & Co. don't check the unused FAT/MDFAT slack for 
        !           269:   errors. I've been reported that these errors can be fixed by setting a
        !           270:   large compression ratio, running scandisk again (now it should find and
        !           271:   correct the errors), and then resetting the compression ratio.
        !           272: 
        !           273: - The dmsdos daemon always exits with an error "Can't get permissions...."
        !           274: 
        !           275:   You are using the *internal* dmsdos daemon which is automatically started
        !           276:   when it is needed. In this case there's no need for the external daemon. 
        !           277:   Watch your process list or look for a
        !           278:   '#define INTERNAL_DAEMON' in dmsdos-config.h. (The internal daemon is a
        !           279:   kernel process like kflushd or nfsiod.) See file dmsdos.doc for details.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.