![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to troubleshooting.doc CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GPL Stacker compression] / dmsdos / doc|
Return to troubleshooting.doc CVS log | Up to [GPL Stacker compression] / dmsdos / doc |
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.