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