![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to dmsdos.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 dmsdos.doc CVS log | Up to [GPL Stacker compression] / dmsdos / doc |
1.1 root 1: dmsdos.doc
2:
1.1.1.2 ! root 3: This is the main documentation for the DMSDOS CVF module. 01MAR1999
1.1 root 4:
5: ------------------------------------------------------------------------------
6:
1.1.1.2 ! root 7: This is version 0.9.2.1.
1.1 root 8:
1.1.1.2 ! root 9: This version has been designed for Linux 2.2.2, but it should run under all
! 10: 2.2.x kernels. It also works with kernels from 2.0.29 to 2.0.36. It very
! 11: likely also works with older ones, but it has at least been reported to fail
! 12: with 2.0.0. For the 2.1.xx series you need at least 2.1.80 though it is
! 13: recommended to use 2.1.94 or newer.
1.1 root 14:
15: Installation notes see file ../INSTALL.TXT.
16:
17:
18: Contents:
19:
20: 1. DMSDOS capabilities
21: 2. Restrictions
22: 3. Mount options
23: 4. Kernel messages [moved to file messages.doc]
24: 5. Installation [moved to file ../INSTALL.TXT]
25: 6. Troubleshooting [moved to file troubleshooting.doc]
26: 7. Defragment procedures
27: 8. How to contribute to dmsdos development
28: 9. The external dmsdos utility 'dutil'
29: 10. The dmsdos daemon 'dmsdosd'
30: 11. The dmsdos library 'libdmsdos.a'
31: 12. The dmsdos filesystem checker 'dmsdosfsck'
1.1.1.2 ! root 32: 13. The dmsdos Midnight Commander external filesystem utility 'mcdmsdos'
! 33: 14. Authors and email addresses
1.1 root 34:
35: ------------------------------------------------------------------------------
36:
37:
38: 1. DMSDOS capabilities
39: ------------------------------------------------------------------------------
40:
41: * 'mount'
42: - doublespace/drivespace compressed msdos 6.x partitions (read-write),
43: - doublespace and drivespace 3 compressed win95 partitions (read-write),
44: - and stacker 3 and 4 compressed partitions (read-write)
45: under Linux via the loopback block device
46: * supports compressed floppies (yes, and even cdroms[**])
47: * can use umsdos extensions in compressed partitions
48: * when writing, compression level may be selected by user
49: * supports standard text conversion like the msdos driver
50: * simple internal fs check on mount (can be switched off)
51: * dmsdos daemon for compressing data in the background
52: * works with all drivers that base on the fat driver, also with FAT32
1.1.1.2 ! root 53: * stand-alone dmsdos library for CVF related programming
1.1 root 54: * stand-alone dmsdosfsck (experimental)
1.1.1.2 ! root 55: * various other utilities
1.1 root 56:
57: [**] No, don't really think of burning a CVF onto a cdrom. Dos cannot read
58: it unless you copy it to your hard disk. REALLY BAD. Linux+dmsdos can.
59:
60: In detail:
61:
62: Dos compressed partitions are always stored inside an uncompressed host
63: partition as large files (CVFs, Compressed Volume Files). In order to
64: access them from Linux, you need
65: * the CVF-FAT interface, which is present in kernels 2.1.80 and newer
66: and must be patched into the 2.0.xx kernel series - the patches are
67: included in this dmsdos release
68: * and the loopback block device.
69: The latter lets you mount a file as a filesystem. You must compile the
70: loopback block device into your kernel or as a loadable module in order
71: to use this feature.
72:
73: This version works with compressed hard disks and with compressed floppies.
74: It has been tested successfully with MS-DOS 6.2 Doublespace and MS-DOS 6.22
75: Drivespace compressed formats. win95 doublespace is supported, also the
76: drivespace 3 format from the Micro$ Plus package (rumors tell that this
77: package has been integrated into Win95OSR2). Stacker version 3 and 4
78: are supported too. Dmsdos can even mount CVFs from cdrom (Dos can't).
79:
80: Francesco Potorti([email protected]) has reported that dmsdos
81: also mounts Superstore compressed filesystems. I can't test this as I
82: don't have Superstore. They are recognized as old Dos 6.0 Doublespace
83: format. I'm interested in further reports about this. I still can't
84: believe that M$ simply copied (bought?) Superstore and renamed it to
85: Doublespace without further modifications...
86:
1.1.1.2 ! root 87: Since version 0.9.0, dmsdos runs *below* the msdos/fat filesystem. This
! 88: makes it compatible with all fat based filesystems including FAT32, NLS
! 89: and other things :)
1.1 root 90:
91: Dmsdos does a lot of internal caching in order to reach a reasonable speed
92: with a compressed (and really badly organised, but simple) filesystem. As
93: a side effect, this cache may eat a lot of system memory (you can change the
94: size limit).
95:
96: Dmsdos was initially inspired by the THS filesystem (once found under
97: ftp://sunsite.unc.edu/pub/Linux/system/Filesystems/dosfs/thsfs.tgz)
98: written 1994 by Thomas Scheuermann (email address out of date), which was
99: the first filesystem available under Linux that could read some CVFs.
100:
101: When mounting a compressed filesystem, the dmsdos driver does some quick
102: and simple consistency checking. If it finds a serious filesystem error
103: that might cause further damage on write access, it sets the compressed
104: filesystem to read-only mode. The filesystem check can be switched off if
105: you don't like it.
106:
107: The dmsdos daemon included in this release can speed up dmsdos write
108: access on systems that usually run at high processor load using delayed
109: compression in the background when the system is idle. I recommend to
110: use it if you are going to write much to compressed partitions from Linux
111: and need the processor time mostly for other tasks. The daemon also has a
112: significant effect on dmsdos memory management which might be important
113: for systems with little memory (well yes, dmsdos *is* a memory monster
114: that can eat up to 2MB of system memory for caching in the default
115: configuration). See chapter 'The dmsdos daemon' for details.
116:
117: The dmsdos library is a stand-alone tool for raw CVF programming.
118: 'Stand-alone' means that it works independently from the dmsdos kernel
119: module, on *raw* CVFs (i.e. those large files lying around in an
120: uncompressed host partition). It's the same source code, though, just
1.1.1.2 ! root 121: compiled in a slightly different way. Meanwhile, it compiles even under
! 122: Windows :)
1.1 root 123:
124:
125: 2. Restrictions
126: ------------------------------------------------------------------------------
127:
128: (See also file BUGS for a list of known bugs.)
129:
130: Performance degradiation (well, not really bad in most cases...)
131: ------------------------
132:
133: Access to compressed filesystems slows down your system. This is a fact
134: that results from additional time needed to decompress or compress the
135: data and to maintain additional filesystem structures. It's an untrue
136: rumor (sometimes spread by compressed filesystem software sellers) that
137: compressed filesystems speeded up slow ISA bus systems because of the
138: smaller amount of data to be transferred through the slow ISA bus -
139: there's too much overhead otherwhere.
140:
141: Though most time-consuming actions like compression and finding free
142: sectors have been greatly improved since dmsdos 0.8.0, there are still
143: sudden system freezes reported. Reasons for this include (in rising order):
144:
145: * Decompressing the data takes some time, but that is supposed to be
1.1.1.2 ! root 146: minimal. You will probably not notice it.
1.1 root 147:
148: * Badly written programs issuing many redundant reads. Such programs
149: kill performance on every filesystem, but it's extremely bad under
150: dmsdos because of the filesystem layout.
151:
152: * Large files, especially accessing them near their end. Again the
153: filesystem layout is the cause. (How do you find the end of a file
154: in a fat filesystem? Right, read the fat. And if the file is large
155: there are tons of fat access necessary to find the end.)
156:
157: * Huge directories. It's again the fat access problem like above. (In
1.1.1.2 ! root 158: 2.1/2.2 kernels it's faster due to the gain from dentry caching.)
1.1 root 159:
160: * Compression on write access. Compression speed depends heavily on
161: the data to compress. In general you can say, the better the data
162: compress the faster the compression.
163:
1.1.1.2 ! root 164: * Compressing incompressible data (on write access). This only wastes
! 165: time since the driver throws the compressed data away and uses the
! 166: uncompressed data if the compressed data turn out to be in fact
! 167: larger. The only thing you can do against this is disabling
! 168: compression if you know the data you want to write don't compress
! 169: any more (e.g. when writing already compressed files).
! 170:
! 171: * Highly fragmented (at internal MDFAT level) filesystems on write
! 172: access. This puts the search algorithm that searches for free space
! 173: in a long loop finding a fitting hole for data to be written. This is
! 174: probably the most important reason for sudden system freezes. It's
! 175: also the most annoying one since there's really nothing to do against
! 176: it. This kind of fragmentation is normal to every compressed
! 177: filesystem and cannot be avoided. The more you write the worse it
! 178: becomes. (See below for details on that kind of fragmentation. Note
! 179: that it's very different from that FAT level fragmentation known from
! 180: FAT based filesystems.)
1.1 root 181:
182: Compression and free sector finding may be fine-tuned with some of
183: the dmsdos options. This is not really explained here, see mount
184: options cf:xx and speedup:xx.
185:
186: Dmsdos never freezes the system totally, it periodically unfreezes even on
187: extremely hard disk access. You *can* login into another console and you
188: *can* enter commands there. No keystroke gets lost though you may not see
189: a reaction on the console immediately, but after some seconds you should
190: see something. Just be warned and prepared :)
191:
192: Compressed formats
193: ------------------
194:
195: The scheme I named the compression methods is simply this: Take the first
196: four bytes of a compressed cluster. For the DS-0-2 method, for example,
197: they are 'D','S',0x00,0x02.
198:
199: Format: Used by: Readable: Writable:
200: DS-0-0 win95 doublespace yes yes
201: DS-0-1 never reported to exist works in theory :)
202: DS-0-2 msdos 6.2 doublespace yes yes
203: JM-0-0 msdos 6.22 drivespace yes yes
204: and win95 drivespace 3 yes yes
205: JM-0-1 win95 drivespace 3 'High' yes yes
206: SQ-0-0 win95 drivespace 3 'Ultra' yes yes
207: uncompressed all versions yes yes
208: (no header) Stacker 3 yes yes
209: 0x81-0 Stacker 4 yes yes
210:
211: Yes, meanwhile all currently known methods are supported (hmm, why is this
212: still listed under restrictions...)
213:
214: Fragmented clusters in drivespace 3 volumes
215: -------------------------------------------
216:
217: They can be read since dmsdos 0.8.1pl5. They can be written since
218: 0.9.0pl10, but writing fragmented clusters is supposed extremely
219: experimental. If dmsdos needs to rewrite data that are stored in a
220: fragmented cluster it first deletes the old data and saves the new
221: data in the usual linear order. Fragmentation writes are only done
222: if the data do not fit on the disk in an unfragmented way. Currently,
223: dmsdos becomes VERY noisy when it writes fragmented clusters...
224: This is considered experimental and needs further testing. You can
225: currently switch off this feature by setting speedup bit#8 (this is
226: a mount option, see below).
227:
228: Fragmented and suballocated clusters in Stacker volumes
229: -------------------------------------------------------
230:
231: Of course, they can be read. But currently, they cannot be written.
232: If dmsdos needs to rewrite data that are stored in a fragmented or
233: suballocated cluster it currently deletes the old data and saves the new
1.1.1.2 ! root 234: data in the usual linear order. Fragmented write may come soon,
! 235: suballocated write is more complex and currently considered not very
1.1 root 236: important for dmsdos. We'll see...
237:
238: Swapping to a file on the compressed partition
239: ----------------------------------------------
240:
241: Just No. It doesn't work. Don't bother me with ideas of swapping to a
242: compressed ram disk which would be a memory compressor... bah!
243: That's all gibberish, crap, and dogsh*t. I won't write code to support
244: this. You know very well that swapping has to be extremely fast, so use
245: a partition on your fastest disk for this purpose. Not a swapfile, and
246: never in a fat based filesystem (just imagine what a filesystem driver
247: has to do in order to access the *end* of a large file... yeah, tons
248: of fat access...)
249:
1.1.1.2 ! root 250: attention, DOSEmu users
! 251: -----------------------
1.1 root 252:
253: You may have to unmount all fat based partitions before running
1.1.1.2 ! root 254: DOSEmu depending on your configuration. If DOSEmu is configured to use
! 255: wholedisk or partition access (this is often the case to let DOSEmu access
1.1 root 256: compressed partitions) there's a risk of destroying your compressed
257: partitions or crashing your system because of confused drivers.
258:
259: Let me explain why. Dmsdos does a lot of internal caching, but cache
1.1.1.2 ! root 260: contents won't be up to date if DOSEmu directly modifies the disk. This
1.1 root 261: confuses dmsdos and may mess up your data. On the other hand, dos
262: dblspace/drvspace.bin also has a kind of caching mechanism that gets
263: confused by the Linux dmsdos driver's write access. Confusion even
264: occurs if one party mounts read-only and the other mounts read-write.
265:
266: Note that it is always safe to redirect the compressed partitions with
267: lredir or emufs.sys. Refer to this table for configurations that are safe
268: (marked with +) and which are dangerous (marked with -):
269:
1.1.1.2 ! root 270: DOSEmu: Linux fat-based filesystems:
1.1 root 271: -------------- --------------------------------
272: not mounted mounted
273: mounted ro rw
274: wholedisk ro + + -
275: wholedisk rw + - -
276: partition ro + + -
277: partition rw + - -
278: lredir/emufs.sys ro/rw + +
279:
280: Memory mapping
281: --------------
282:
283: *Should* work. :^)
284:
285: Underlying dos filesystem limitations
286: -------------------------------------
287:
288: None. Really, they're gone since the CVF-FAT interface is used.
289:
290: Umsdos users warning
291: --------------------
292:
293: If you want to use umsdos-style long filenames in compressed filesystems,
294: use kernel 2.0.xx or get at least kernel 2.1.94.
295:
296: Win98 compatibility
297: -------------------
298:
1.1.1.2 ! root 299: HEY! Windows People !
! 300: Everyone uses it in the Windows World(TM) :)) Let me know whether
! 301: it works, please. (I refuse to buy Win98 just for such a test.)
! 302: Or have you all switched to WinNT yet ?
! 303:
! 304: WinNT compatibility
! 305: -------------------
! 306:
! 307: No, WinNT does not support compressed FAT partitions. But...
! 308: :))
! 309: There's meanwhile a small chance to port dmsdos to WinNT. This is
! 310: somewhat interesting because neither Doublespace nor Stacker runs under
! 311: WinNT. But I can't do it myself because of lack of knowledge :( For more
! 312: information, see file PORT_TO_WIN32. The trick is hacking in the dmsdos
! 313: library so it compiles under that operating system... I just managed to
! 314: compile one dmsdos utility, mcdmsdos, under WinNT...
1.1 root 315:
316: Last but least
317: --------------
318:
319: Dmsdos has been written for dos/win95 compatibility. It's just a relict
320: from the time when I programmed some software that had to run both under
321: dos and Linux and I had to compress my drive because hard disk space was
1.1.1.2 ! root 322: rather expensive. Times and prices have changed a lot since then (at least
! 323: in the country where I live), but dmsdos has still been improved for fun.
1.1 root 324:
325: If you don't need dos/win95 compatibility, i.e. if you want to compress
326: Linux-only data, let me say: DON'T DO IT. Clean up your disk, or buy a
327: larger one, but don't compress it. Really. Compress single files (e.g.
328: manpages) with gzip. Throw away the crap you don't need. Shrink your
329: dos partition or remove it completely :)
330:
331: If you still want to compress Linux data, dmsdos may not be the software
332: you want. The msdos filesystem is extremely unsuited for fast disk access,
333: umsdos suffers from it too. The CVF structure msdos uses is even more
334: unsuited, and the time required by msdos online compression may kill the
335: rest of Linux' performance on these filesystems.
336:
337: Just to let you know about some other online compression software for Linux:
338: There's a package 'double' available on sunsite for Linux online
339: compression. There are also compression patches for the ext2 filesystem
340: available under the name 'hufs' and 'e2compr'. I've also heard about a
341: 'zlibc' project which lets you access gzip compressed files as if they were
342: uncompressed - it works by a patched libc. Look at common Linux ftp sites.
343:
344: Like dmsdos, all those packages may have their specific advantages and
345: disadvantages. Some are said to be not 100% stable, but who can claim that
346: his software is really 100% stable :-) Please don't flame at me if the
347: packages don't do what you want - I haven't tested them and I don't know
348: much about their qualilty.
349:
350:
351: 3. Mount options
352: ------------------------------------------------------------------------------
353:
1.1.1.2 ! root 354: CVF related mount options are usually surrounded by the CVF-FAT interface
! 355: options. These are "cvf_format=xxx" and "cvf_options=yyy". The string "xxx"
! 356: can be "dblspace" for a doublespace or drivespace CVF and "stacker" for a
! 357: stacker CVF. For more information about the "cvf_format=xxx" option,
! 358: especially in cooperation with kerneld and automatic module loading, see
! 359: the dmsdos installation instructions (file INSTALL.TXT) and the generic
! 360: CVF-FAT documentation (file linux/Documentation/filesystems/fat_cvf.txt).
! 361:
! 362: When we speak about dmsdos mount options, we usually mean the string "yyy" in
! 363: "cvf_options=yyy". That's what this chapter describes.
! 364:
1.1 root 365: Summary:
366: --------
367:
368: The dmsdos driver currently recognizes the following options:
369:
370: comp:xxx, cf:xxx, bitfaterrs:xxx, loglevel:xxx, speedup:xxx
371:
1.1.1.2 ! root 372: (for backwards compatibility also comp=xxx, cf=xxx, bitfaterrs=xxx and
1.1 root 373: loglevel=xxx, speedup=xxx are accepted)
374:
375: The xxx has to be replaced by an appropriate parameter, of course. All
376: options have to be specified separated by plus signs (not commas) in a list
377: in the mount command:
378: 'mount -t msdos -o cvf_options=option1+option2+option3 ...'.
379: Consider the string 'cvf_options=option1+option2+option3' as *one* FAT
380: driver option! For backwards compatibility, also a dot (.) is recognized
381: as option separator symbol.
382:
383: comp:xxx
384: The comp option selects which compression method to use for compressing
385: files when they are written to a compressed partition. The default value
386: (which is used if no comp option is specified) is hard-coded to guess.
387:
388: Don't get confused by this list. Dmsdos usually determines automatically
389: the right and, if there's a choice, the best compression for you (by
390: scanning the filesystem and analysing the compressed data written by
391: dos/win95). But if you explicitely tell dmsdos to use a specific
392: compression, the driver does what you tell it to do. So be careful.
393:
394: comp:no Selects no compression for write access i.e. all files written
395: to a compressed partition are stored in fact uncompressed.
396: This option may speed up write access, but doesn't make much
397: sense on a compressed filesystem (except for debugging).
398: comp:ds00 Selects DS-0-0 compressed format for write access. This is
399: win95 native format if you don't have drivespace 3. This
400: format may also be used for Stacker 3 and 4 (though not
401: recommended for them as it's not the native Stacker format).
402: comp:ds01 Obsolete. DS-0-1 has never been reported to exist. So what.
403: comp:ds02 Selects DS-0-2 compressed format for write access. This is
404: dos 6.0-6.2 (*not* 6.22) format. Under dmsdos, it is rather
405: identical to DS-0-0 except for the compression header.
406: comp:jm00 Selects JM-0-0 compressed format for write access. This is
407: dos 6.22 format and win95 drivespace 3 'Normal' format.
408: comp:jm01 Selects JM-0-1 compressed format for write access. This is
409: win95 drivespace 3 'High' format. Note that it is rather
410: identical to JM-0-0 in dmsdos (but not in win95).
411: comp:sq00 Selects SQ-0-0 compressed format for write access. This is
412: win95 drivespace 3 'Ultra' format. Only drivespace 3 is
413: known to be able to handle this format.
414: comp:sd3 Selects SD-3 compressed format for write access. This is
415: Stacker 3 format. It may be used for Stacker 3 and 4.
416: comp:sd4 Selects SD-4 compressed format for write access. This is
417: Stacker 4 standard format. It may only be used for Stacker 4.
418: comp:guess Tries to find out automatically which compression method
419: dos used to create the compressed partition and selects the
420: appropriate format. If guessing fails, no compression is used
421: and a message is printed in the syslog.
422:
423: WARNING: You *can* specify senseless options in the command line, for
424: example, mount a doublespace drive and select stacker compression.
425: You may end up in a mess in that case.
426:
427: NOTE: It's not true that JM-0-1 (Drivespace 3 'High') compresses better
428: than JM-0-0 (Drivespace 3 'Normal'), at least under dmsdos. Set the
429: compression effectivity with the cf:xx option. In fact, dmsdos uses the
430: same routine to compress DS-0-0, DS-0-1, DS-0-2, JM-0-0 and JM-0-1
431: (they are almost equal, so similar that only, for example, the meaning
432: of one bit is different or some constant offsets differ). It's just
433: true that SQ-0-0 is more powerful than the DS and JM formats, and also
434: SD-4 is more powerful than SD-3. Also, one can say that SD-3 has
435: something in common with the DS and JM formats. Yes, SD-4 and SQ-0-0
436: have some similarities, too, but I really can't say which one is best.
437:
438: cf:xx (where xx is a decimal number from 1 to 12)
439: Selects the compression effectivity and speed. Since compression
440: effectivity always runs in concurrence to speed, try some values and
441: watch what happens. 1 is fastest but least efficient compression, 12 is
442: most efficient but slowest compression. The default value can be selected
443: before compiling by 'make config' (note that the value minus 1 must
444: be specified there, i.e. the range is from 0 to 11 there).
445:
446: If the external dmsdos daemon is running, this option doesn't have an
447: effect because the daemon doesn't care about this option - it reads the
448: compression level from its command line instead.
449:
450: bitfaterrs:xxx
451: Selects what to do with inconsistencies in the internal filesystem
452: sector allocation table. Default is setting the filesystem read-only.
453:
454: bitfaterrs:repair
455: Repair BITFAT mismatches if there are any when mounting the
456: filesystem read-write. This verifies the BITFAT and corrects
457: allocation errors. It is highly important for write access
458: that the BITFAT has no errors. For read-only access the
459: BITFAT is not needed. In read-only mode, this option is
460: ignored. This option may be dangerous in case dmsdos has
461: not recognized your filesystem correctly. So try without it
462: the first time until you can be sure.
463: bitfaterrs:ignore
464: Ignores BITFAT mismatches. This is dangerous and can cause
465: awful MDFAT level crosslinks as well as complete data loss.
466: Use this setting only if you know what you are doing.
467: bitfaterrs:setro
468: Sets the filesystem to read-only mode if BITFAT mismatches
469: are detected. This is safe and also the default behaviour.
470: bitfaterrs:nocheck
471: Don't check the filesystem's internal tables when mounting.
472: This speeds up the mount process a lot. This option
473: is *not* recommended, of course, unless you are very sure
474: there are no errors in the filesystem.
475:
476: WARNING: Generally, BITFAT mismatches are *severe* filesystem errors.
477: You will destroy your data if you write to a filesystem that contains
478: BITFAT mismatches. Note that Dos seems to check and repair the BITFAT
479: automatically and silently on each bootup, so just booting into Dos may
480: repair those errors.
481:
482: loglevel:xxx
483: Sets the driver's loglevel to xxx (a decimal or, if preceeded by 0x,
484: hexadecimal number). The number is a 32 bit field. Each bit represents a
485: family of messages that will be logged when the appropriate bit is set.
486: See file dmsdos.h for details about the message families (watch out for
487: LOG_SomeThing defines and what bits they use). The meanings of the bits
488: are not documented here since they may differ from version to version.
489:
490: WARNING: You are strongly encouraged to increase your kernel's log buffer
491: size to at least 64KB (it's in file linux/kernel/printk.c:
492: '#define LOG_BUF_LEN size_in_bytes', please note that the size *must* be
493: a power of 2) - otherwise you are likely to lose messages or receive even
494: complete garbage due to log buffer overruns.
495:
496: speedup:xxx
497: Sets the driver's speedup flags to xxx (note: these flags are always the
498: same for all CVFs). xxx is a decimal or (if preceeded by 0x) hexadecimal
499: value. The meanings of these bits are listed below. The speedup is active
500: when the appropriate bit is set.
501:
502: WARNING: You should not use this option or change the default value
503: unless you know exactly what you are doing.
504:
505: *** Less speedup than the default may result in painfully
506: sluggish filesystem access.
507: More speedup than the default may cause dangerous side
508: effects.
509:
510: However, speedup may have to be selectively disabled in order to hunt
511: bugs :)
512:
513: bit #0: Leave directories uncompressed
514: Never compress directories for drivespace 3 and stacker
515: (others don't support compressed directories at all).
516: WARNING: Directories are accessed very often, so it's
517: best not to compress them. Usually set this bit.
518:
519: bit #1: Leave umsdos EMD file uncompressed
520: This is only for umsdos upon dmsdos: never compress the
521: --linux-.--- special file (it contains extended directory
522: information).
523: WARNING: This file is even more often written than a
524: directory since it contains the access times (the
525: directory contains only the modification times). You will
526: regret compressing this file, even if you own the fastest
527: computer of the world. Don't ask, set this bit.
528:
529: bit #2: Skip exact search on BITFAT allocation
530: Search faster but less carefully for free space in bitfat
531: at the cost of more fragmentation. This bit is for
532: sector allocation code. If you set this bit allocation on
533: large CVFs is faster but also causes a little more
534: fragmentation. On the other hand, searching more carefully
535: leads to sudden system freezes for up to some seconds on
536: large partitions. Set this bit if you cannot tolerate
537: them. Usually this bit is cleared.
538:
539: bit #3: Fast unmount
540: Write dirty buffers on unmount immediately without
541: compressing them before. This switch defines what happens
542: with unwritten dirty clusters that are in the cache when
543: the filesystem is unmounted. If the bit is clear it means
544: write them back, but compress them before. If it is set,
545: it means write them back without compression.
546: WARNING: COMPRESSION TAKES SOME TIME, YOU'LL NOTICE IT.
547: If you are prepared to wait even some minutes (on an old
548: 386SX16 - on a P100 this should be max. one second) on
549: unmount you can clear this bit. Usually it is set.
550:
551: bit #4: Enable write-back cluster caching (instead of write-through)
552: If this bit is set the data in the cluster
553: cache that have been changed by an application and have to
554: be written back to disk are not written back immediately -
555: they are kept some time in memory just in order to save
556: disk access when the application again changes the data.
557: There's a small risk of data loss if the system happens to
558: crash before the data are written back - but since your
559: operating system is Linux a crash is rather unlikely :)
560: This bit is usually set. When hunting bugs, it should be
561: cleared since it may prevent finding a way to reproduce
562: a bug.
563:
564: bit #5: Enable cluster read-ahead
565: If this bit is set, this causes the driver to initiate a
566: low-level disk access for some data when it thinks they
567: are most likely needed in a short time later. The trick is
568: that the driver doesn't wait for the disk access to
569: finish. So the disk can position its head (and so on)
570: while the system can do something else. Most likely the
571: disk access has finished when the data are actually needed
572: - this saves some time we otherwise had to wait. Well, at
573: least this is the nice idea of read-ahead. However, since
574: read-ahead relies on a prediction, there may be situations
575: when it is useless or even a loss.
576: This bit is usually set. When hunting bugs, it should be
577: cleared since it may prevent finding a way to reproduce
578: a bug.
579:
580: bit #6: Fast BITFAT allocation
581: Switch to very fast sector allocation. This speeds up
582: bitfat allocation because the search algorithm that tries
583: to avoid fragmentation is simply switched off. BE WARNED,
584: it causes *much* fragmentation in very short time. The
585: "filesystem almost full" warning is suppressed. This
586: switch is meant as a last resort if you cannot tolerate
587: system slowdowns at all. Don't fill the compressed
588: filesystem up to more than 3/4 when this switch is set.
589: Write access may fail horribly and cause data loss due to
590: too high fragmentation.
591: This bit is usually cleared. If you are unsure about the
592: dangers let it cleared. Only set it if you really know
593: what you are doing.
594:
1.1.1.2 ! root 595: bit #7: Use daemon for background conpression if present
1.1 root 596: Use the daemon for delayed compression in the background.
597: This bit is for users of the internal daemon since the
598: internal daemon cannot be disabled by simply killing it.
599: So clearing this bit is another way to disable the daemon.
600: This bit is usually set. When hunting bugs, it should be
601: cleared since it may prevent finding a way to reproduce
602: a bug. *** This bit only affects daemon *compression*.
603: Daemon-controlled memory management still works
604: regardless of this bit.
605:
606: bit #8: Avoid fragmented writes
607: Speedup Bit#8 controls what to do when the filesystem is
608: too fragmented for normal write access. Usually all data
609: for one cluster are stored in contiguous sectors, but if
610: the filesystem is too fragmented there may not be a 'free
611: hole' that is large enough for the data. Speedup Bit#8
612: controls what to do in that case. If this bit is set
613: dmsdos just returns a 'no space left on device' error and
1.1.1.2 ! root 614: refuses to write to the CVF.
1.1 root 615: Drivespace 3 and Stacker know a hack for that situation:
616: they allow storing the data of one cluster in several
617: fragments on the disk. If the bit is clear, the driver
618: tries to write the data in several fragments. Be warned,
619: this makes future filesystem access much slower as it
620: needs more disk head movements to read fragmented
621: clusters.
622: *** Note that for Stacker fragmented writes are currently
623: not implemented. Doublespace and drivespace (version
624: <=2) do not support this at all. So the bit is
625: ignored for them.
626:
627: Default speedup (187) is reasonable for normal read and moderate write
628: access. For high-traffic write access you might want to set additionally
629: bit #2 (speedup:191) or even bit #6 (speedup:255). On quite full
630: or highly fragmented CVFs this makes a *great* difference, but it's up
631: to you to decide between safety and speed.
632:
633: Note:
634: You can use the external utility dutil to setup or change dmsdos options
635: later. Look at the following example commands:
636:
637: dutil /mnt setcomp xxx (for changing the comp:xxx option),
638: dutil /mnt setcf xx (for cf:xx option),
639: dutil /mnt setspeedup xxx (for speedup:xxx option) and
640: dutil /mnt setloglevel xxx (for loglevel:xxx option).
641:
642: Just replace the directory name '/mnt' with your mount point in the
643: examples. Besides, you must be root to change dmsdos options via dutil.
644: The bitfaterrs:xxx option cannot be changed with dutil since it only
645: makes sense at mount time :)
646:
647: The string 'option1+option2+option3...' in the FAT mount option
648: 'cvf_options=option1+option2+option3...' has a hard coded limit of 100
649: characters (this is a limitation of the CVF-FAT interface). The string
650: is silently cut down if it is too long. Don't worry, you won't manage
651: to break the limit without specifying senseless parameters :)
652:
653: For those who want to know everything exactly, the CVF-FAT interface
654: has a further FAT driver option (*not* dmsdos option): cvf_format=xxx.
655: The parameters that the dmsdos module allows for 'xxx' are 'dblspace'
656: (for all doublespace and drivespace versions) and 'stacker' (for all
657: stacker versions). Usually you don't care about them since the formats
1.1.1.2 ! root 658: are detected automatically. They may, however, be useful in order to
! 659: trigger kerneld to load the dmsdos module on demand. For details please
! 660: look at the dmsdos installation instructions (file INSTALL.TXT) and the
! 661: generic CVF-FAT interface documentation (file
! 662: linux/Documentation/filesystems/fat_cvf.txt).
1.1 root 663:
664: And now a warning: If you want to mount a CVF *be sure* to have the
665: dmsdos module loaded. The plain FAT driver also mounts some CVFs without
666: complaining (but begins to scream loudly when you, for example, do
667: a 'ls' on the mountpoint). As some CVFs look very similar to normal,
668: uncompressed filesystems, the FAT driver has no chance to detect a
669: CVF at mount time (and e.g. print an error) when the dmsdos module is
670: not loaded.
671:
1.1.1.2 ! root 672: *** If you always specify a "cvf_format=something" option you never
! 673: run into that problem.
! 674:
1.1 root 675: Some simple examples:
676: 1. Your msdos partition that contains CVFs is on /dev/hda1. You want to
677: mount it under /DOS and the CVF under /mnt.
678: mount -t msdos /dev/hda1 /DOS
679: mount -t msdos -o loop /DOS/dblspace.001 /mnt
680: 2. Like above, but you need umsdos support.
681: mount -t umsdos /dev/hda1 /DOS
682: mount -t msdos -o loop /DOS/dblspace.001 /mnt
683: 3. Like above, but you also have umsdos style long filenames in your CVF
684: mount -t umsdos /dev/hda1 /DOS
685: mount -t umsdos -o loop /DOS/dblspace.001 /mnt
686: 4. Like 1., but you need Win95 long filename support *only inside* the
687: compressed partition.
688: mount -t msdos /dev/hda1 /DOS
689: mount -t vfat -o loop /DOS/dblspace.001 /mnt
690: 5. Like 1., but you want to feel safe and refuse write access to the
691: compressed partitions only (but the uncompressed host should be writable).
692: mount -t msdos /dev/hda1 /DOS
693: mount -t msdos -o ro,loop /DOS/dblspace.001 /mnt
694: 6. Like 4., but you need Win95 long filenames also in the uncompressed host
695: partition
696: mount -t vfat /dev/hda1 /DOS
697: mount -t vfat -o loop /DOS/dblspace.001 /mnt
698: 7. You have managed to burn a compressed filesystem onto a CD (This is
699: quite easy - put the large file 'dblspace.001' into an iso9660
700: filesystem and burn it. Be warned, dos can't mount it from CD. Uh...)
701: mount -t iso9660 /dev/cdrom /cdrom
702: mount -t msdos -o loop /cdrom/dblspace.001 /mnt
703: 8. Like 1., but the CVF has been umssynced and contains umsdos long
704: filenames.
705: mount -t msdos /dev/hda1 /DOS
706: mount -t umsdos -o loop /DOS/dblspace.001 /mnt
707:
708: Some complex examples (I didn't break the long lines herein). The option
709: strings might look strange but they are correct:
710: 9. Like 1, but you want the driver to repair bitfat errors automatically.
711: mount -t msdos /dev/hda1 /DOS
712: mount -t msdos -o loop,cvf_options=bitfaterrs:repair /DOS/dblspace.001 /mnt
713: 10. Like 1, but you need more speedup due to high-traffic write access
714: (well, please note that this is not recommended, but it works):
715: mount -t msdos /dev/hda1 /DOS
716: mount -t msdos -o loop,cvf_options=speedup:255 /DOS/dblspace.001 /mnt
717: 11. Like 9 and 10 (repair bitfat errors and more speedup):
718: mount -t msdos /dev/hda1 /DOS
719: mount -t msdos -o loop,cvf_options=bitfaterrs:repair+speedup:255 /DOS/dblspace.001 /mnt
720: 12. Like 1, but disable write access, ignore bitfat error and do debug
721: logging (be careful, this causes tons of debug messages):
722: mount -t msdos /dev/hda1 /DOS
723: mount -t msdos -o loop,ro,cvf_options=bitfaterrs:ignore+loglevel:0xffffffff /DOS/dblspace.001 /mnt
724:
725: Mounting via /etc/fstab:
726:
727: This may be a bit tricky. A typical fstab entry for a CVF looks like this:
728:
729: /DOS/drvspace.001 /DOSF msdos loop 1 0
730: /dev/hda1 /DOS msdos defaults 1 0
731:
732: Be sure to keep the sixth field (the 'pass number') zero to prevent fsck
733: from checking the CVF (it does not know about CVFs and very likely fails).
734: Also the filesystems in /etc/fstab seem to be mounted in reverse order,
735: but that may depend on your mount or libc version. Try to reorder the
736: lines it it doesn't work.
737:
738:
739: 4. Kernel messages
740: ------------------------------------------------------------------------------
741:
742: This section has moved to file messages.doc.
743:
744:
745: 5. Installation
746: ------------------------------------------------------------------------------
747:
748: This section has moved to file INSTALL.TXT in the main dmsdos directory.
749:
750:
751: 6. Troubleshooting
752: ------------------------------------------------------------------------------
753:
754: This section has moved to file troubleshooting.doc.
755:
756:
757: 7. Defragment procedures
758: ------------------------------------------------------------------------------
759:
760: There are three possibilities for fragmentation of a compressed partition:
761: - Msdos FAT level: The CVF itself is a file in a msdos partition that
762: might be broken into several fragments.
763: - Internal FAT level: The files stored in the CVF are fragmented in a
764: similar way like FAT level fragmentation on a real dos partition. Unlike
765: in a real msdos partition, filesystem access does *not* suffer from this.
766: There is no need for defragmenting a CVF at this level (except that you
767: want to make the CVF smaller - then it may be necessary).
768: - Internal MDFAT level: Worst fragmentation that can happen in a CVF. All
769: write access (not only file creation and deletion) causes MDFAT level
770: fragmentation. If a CVF is too fragmented at this level, write access
771: even fails as if the disk was full. Defragmenting a CVF usually refers
772: to this kind of fragmentation, which is very different from FAT level
773: fragmentation.
774:
775: How to defragment a CVF at internal MDFAT level see your dos/win95 or
776: stacker documentation. Dmsdos does not support CVF maintainance.
777:
778:
779: 8. How to contribute to dmsdos development
780: ------------------------------------------------------------------------------
781:
782: First of all, thanks a lot to all alpha testers and all who have sent problem
783: reports, found bugs in the sources or documentation, suggested solutions to
784: some problems and asked questions due to unclear documentation. Without your
785: help dmsdos would not have become what it is.
786:
787: Also many thanks to all who simply mailed they liked dmsdos.
788:
789: At this place, I must also say many thanks to Gordon (VFAT fs) and Matija
790: (UMSDOS fs) for the help to make dmsdos work with the standard 2.1.xx
791: kernels.
792:
793: If you have a problem that is not covered in the documentation please email
794: me. But, *please*, be sure to read the file 'troubleshooting.doc' before.
795: If it's not mentioned there, you may have uncovered a bug that
796: should be fixed. Please watch your kernel log (/var/log/messages) for
797: strange dmsdos messages too. Please include the following information in your
798: mail message:
799:
800: - Linux kernel version, dmsdos version (see kernel messages).
801: - If it doesn't compile, gcc version, as version, libc version, make version.
802: - MS-DOS version you a) used to create the compressed partition, b) you
803: currently use.
804: - Dmsdos kernel messages that are produced when the problem occurs.
805: - Information about your disk hardware (hardware sector size is important -
806: there are some hacks for hardware sector sizes != 512 bytes in the code)
807: - Size of the real (uncompressed) dos partition.
808: - dutil output (run it on the dmsdos CVF directory that causes problems).
809: - Everything else, of course, you think I need to know about the problem.
810: - A valid email address (I wouldn't write this if I hadn't received some
811: mails I couldn't reply to because the return address was rejected).
812:
813:
814: 9. The external dmsdos utility 'dutil'
815: ------------------------------------------------------------------------------
816:
817: (For a summary, take a look at the dutil manual page (file src/dutil.1).)
818:
819: Run dutil on a dmsdos mount point to obtain additional information about the
820: compressed partition. Example: 'dutil /mnt'. This utility has
821: some additional debugging options. These are not described here since they
822: are for debugging only. Run dutil with debug options only when you are asked
823: by the dmsdos author/maintainer in a response to any problem report.
824:
825: Note: Debugging options require running dutil as root. Other users can only
826: see the general filesystem information dutil prints on the screen. See file
827: dblspace_ioctl.c for details on what can be done only by root.
828:
829: You can use the external utility dutil to setup or change dmsdos options
830: later. Use 'dutil /mnt setcomp xxx' (comp:xxx option) and
831: 'dutil /mnt setcf xx' (cf:xx option). Note to replace the directory name
832: '/mnt' with yours. This also works: 'dutil /mnt setspeedup xxx'
833: (speedup:xxx option) and 'dutil /mnt setloglevel xxx' (loglevel:xxx option).
834: The dmsdos options can only be changed by root.
835:
836: To perform a simple filesystem check, use the command
837: 'dutil /mnt checkfs'. This fs check doesn't do any repairs, but
838: immediately reports some fs inconsistencies. There shouldn't be any unless
839: the driver complained already at mount time (see kernel log). If there are
840: errors and the dmsdos driver didn't find them at mount time, this is a
841: serious dmsdos bug (it implies that data have been destroyed by the dmsdos
842: driver) and should be reported. If the command complains about errors but
843: the dos fs checker says everything is okay, you should also send a bug
844: report.
845:
846: To sync the write-back cache you can use 'dutil /mnt synccache'.
847: By default, the command waits until the data have been passed to the kernel's
848: filesystem buffering interface. (If you want to ensure that they are really
849: physically written issue a 'sync' afterwards which causes the kernel to
850: write all dirty buffers to disk.) You can specify an additional argument !=0
851: in order to pass the cache contents to the daemon instead of writing directly
852: to disk (not useful if you want to ensure that the data are written *now*).
853:
854: Note that dutil displays two different compression ratios - an internal and
855: an external one. The internal one is always lower and is used to estimate
856: how much space is left on the device. It depends on which information can
857: actually be obtained from the MDFAT without scanning the whole disk (would
858: take too much time). If you want to compare different versions of compressed
859: filesystems to each other (e.g. doublespace vs. stacker) concerning the
860: compression effectivity, always use the external (second) one because it is
861: always calculated in the same manner. The external compression ratio is
862: calculated according to this formula:
863:
864: Space that would be used on an equivalent uncompressed msdos filesystem
865: ------------------------------------------------------------------------- : 1
866: Space that is used on the disk
867:
868: 'Space' means what file and directory clusters occupy, it does *not* mean:
869: FAT, root directory, futher filesystem maintainance information.
870:
871:
872: 10. The dmsdos daemon 'dmsdosd'
873: -----------------------------------------------------------------------------
874:
875: The dmsdos daemon is a program that runs in the background and
876: does delayed compression when the system is idle. This prevents the dmsdos
877: driver from slowing down your system when compressing large amounts of data.
878: In newer dmsdos versions, the daemon has also some influence on dmsdos
879: memory usage (it shrinks the amount of memory dmsdos eats for caching if
880: the dmsdos driver has not much to do). This might be an advantage for
881: systems that are short on memory.
882:
883: Actually, the daemon exists in two variants. The first one is a user-level
884: process (dmsdosd) that must be started with a command line
885: like 'dmsdosd /mnt' or 'dmsdosd /mnt xx', where /mnt is the mount point
886: and 'xx' is the compression level like in the cf:xx mount option. If the
887: xx is omitted it defaults to 12 (i.e. maximum compression). Please note
888: that this variant of the dmsdos daemon does not care about the dmsdos cf:xx
889: option or the dutil setcf command, but uses its own from its command line.
890: This variant of the dmsdos daemon is called 'external daemon'. For a summary
891: concerning this variant of the dmsdos daemon you can also take a look at the
892: dmsdosd manual page (file src/dmsdosd.1).
893:
894: The second variant is built inside the kernel and starts up automatically
895: when it is needed and exits when it is no longer needed. This variant is
896: called 'internal daemon' and cannot be killed from user space, not even by
897: root. It also obeys the cf:xx option and the dutil setcf command.
898:
899: You can only use one daemon at a time. You must decide before compiling
900: dmsdos which variant to use. During dmsdos configuration ('make config')
901: you are asked which one you want. Both daemon variants do the same work, but
902: the internal one is more user-friendly (well, you don't have to start it
903: manually :-) ) while the external one is more flexible and seems to eat up
904: less system time (but has other backdraws - you must kill it before you can
905: unmount the filesystem that has been given as a command line argument). If
906: you are using the internal daemon, the external one won't start - it always
907: exits with a "no permission" error.
908:
909: If you are going to use the external daemon, please note this: DON'T start
910: one daemon for each filesystem. The one single daemon does all the work for
911: the filesystem given in its command line and for all other dmsdos
912: filesystems you have currently mounted and for all other dmsdos filesystems
913: you mount later while the daemon is running. To prevent security problems
914: only root can start the external daemon (and even more, the driver refuses
915: to talk to a non-root dmsdos daemon via the ioctl interface). The external
916: daemon may be killed (by root) at any time, even when it is under hard work.
917: Send a SIGINT to it to let it finish its actual work and then exit. Send a
918: SIGTERM to it to make it exit immediately. In any case, the daemon catches
919: the signals and exits cleanly.
920:
921: The dmsdos daemon works like this: When it starts up, it tells the dmsdos
922: driver not to compress the data when doing write access to the compressed
923: filesystem. Instead, the driver writes the *uncompressed* data to the disk
924: and maintains a list of clusters that have to be compressed. When the daemon
925: has time to do something, it asks the driver for a cluster to compress. Then
926: the driver looks up a cluster in its 'clusters-that-must-be-compressed'
927: list, reads it from disk and passes it to the daemon. The daemon itself now
928: compresses the data. When it has finished compression, it passes the
929: compressed cluster back to the driver, which in turn writes it to the disk.
930:
931: There are two situations the list gets lost and the data that have not yet
932: been compressed by the daemon remain uncompressed on the disk:
933:
934: 1. Rebooting the system clears the whole list.
935: 2. Unmounting the filesystem clears all the list entries that
936: contain clusters of the filesystem to be unmounted.
937:
938: Please note that this kind of "cache" has a limited size. If you exceed that
939: size by writing *much* data at once the dmsdos driver no longer lets the
940: daemon do the job, but starts to compress the data itself. You will notice a
941: moderate system slowdown in that case. In extreme situations you might not
942: even see an immediate reaction on a keystroke, but those cases have become
943: rare. (If you suddenly see a *great* system slowdown this is usually caused
944: by too much fragmentation - not by compression.)
945:
946: The size of this "cache" can be selected during 'make config'. The number
947: specified there means the maximum (i.e. total, not per CVF) number of
948: clusters that can be in the list. If you want to know the amount in bytes,
949: multiply with the cluster size (which is 32KB for drivespace 3 and 8KB for
950: the other compressed filesystems). The dmsdos driver may use up to this
951: amount of _uncompressed_ disk space inside each compressed partition as
952: "cache". You can use dutil to find out how much uncompressed free space is
953: on the disk. If it is less than the "cache" size you shouldn't write more
954: than the amount of uncompressed free space to the disk at once. Otherwise,
955: the disk is getting full with the cached uncompressed data and you receive
956: a 'no space left on device' error.
957:
958: If there's nothing to compress any more the daemon goes to sleep mode, but
959: when the dmsdos driver needs the daemon it tries to awake it immediately.
960: Furthermore, the daemon awakes periodically to check for data and inform
961: the driver when it is time to release memory.
962:
963: Please note that using the daemon causes *duplicate* write access to the
964: filesystem. This results in a lot of more MDFAT level fragmentation. Thus,
965: the daemon cannot really make your system faster. In fact, it only makes
966: your system *appear* faster by doing a kind of load balancing. This load
967: balancing avoids unnecessary locks (kind of wait loops) in the driver. It
968: means the time some processes would have to wait can be used by other
969: processes.
970:
971: As I'm sometimes asked what to recommend: For a system with read-only or
972: very little write access and enough memory you don't need the daemon. For a
973: system with moderate write access and an appropriate fast processor the
974: internal daemon is best choice. For a system with moderate to high-traffic
975: write access to compressed partitions I recommend the external daemon.
976: If you have a slow processor and you need CPU time for some other intensive
977: computing, it's best to use the external daemon with a nice value (see
978: 'man nice') - this prevents the daemon from slowing down the other
979: processes. If the daemon does not compress fast enough try to lower the
980: compression level in its command line. Well, and if you want to write a
981: large chunk of data (some 100MB) to a compressed partition at once, disable
982: the daemon before - it cannot help in this situation. It only causes too
983: much fragmentation which in turn slows down the system horribly.
984:
985: Just another hint: If you want to use the daemon only for memory management
986: but not for delayed compression, you can clear speedup bit #7.
987:
988: You see, there's much room for experimentation here, especially if you use
989: the external daemon :) There are some pre-configured dmsdos config files
990: which just implement some of the above recommendations. This is explaind
991: in INSTALL.TXT so see there for details, please.
992:
993:
994: 11. The dmsdos library 'libdmsdos.a'
995: -----------------------------------------------------------------------------
996:
1.1.1.2 ! root 997: This feature is currently experimental, but begins to become more and more
! 998: interesting.
1.1 root 999:
1000: The dmsdos library is intended to provide some low-level dmsdos functions
1001: to user processes. The library is not new source code - it's just the
1002: dmsdos module source compiled in a different way (well, with some tricks).
1003: The dmsdos library aims towards working with raw CVFs, not filesystems.
1004: It is usable only for *not* mounted CVFs. Well, for mounted ones there's
1005: the dmsdos module :)
1006:
1.1.1.2 ! root 1007: Documentation (including a detailed description of the interface functions)
! 1008: can be found in file libdmsdos.doc.
1.1 root 1009:
1010:
1011: 12. The dmsdos filesystem checker 'dmsdosfsck'
1012: ------------------------------------------------------------------------------
1013:
1014: The goal of dmsdosfsck is not having a complete and reliable filesystem
1015: checker for CVFs. If you want that, use the filesystem maintainance tools
1016: that came with your CVF software package under Dos (or blame their
1017: manufacturers if they are not working well...). dmsdosfsck is just meant
1018: as a kind of workaround for problems that may show up if the dmsdos or
1019: FAT driver suddenly detects an unexpected inconsistency and might get
1020: confused. With dmsdosfsck those problems that may confuse the drivers can
1021: be detected and corrected before mounting the CVF.
1022:
1023: The command line of dmsdosfsck looks like this:
1024:
1025: dmsdosfsck [-a] [-r] [-v] [-l] device|file
1026:
1027: where -a means repair automatically (uh... be VERY careful), -r means
1028: repair interactively, -v means be verbose, and -l means list the files
1029: while processing them. These options are somewhat similar to the well-known
1030: dosfsck.
1031:
1032: Currently not all errors can be corrected. It just corrects fatal FAT
1033: errors like loops, crosslinks, illegal values, and unexpected ends of
1034: chains - things the kernel FAT driver does not like at all and tends to
1035: crash or hang if it runs over them. (Well, this is a question of philosophy.
1036: Should a kernel driver be idiot proof or may it assume the filesystem is
1037: valid in most cases at the most vital places? I don't want to give an
1038: answer, but the FAT driver of Linux 2.0.34 seems not 100% idiot proof.)
1039: So there is really a need for a dmsdosfsck utility here.
1040:
1041: Furthermore, it can detect but not correct MDFAT errors, crosslinks,
1042: damaged MDFAT entries - you must repair them under Dos using the CVF
1043: maintainance tools that came with your CVF software package. The kernel
1044: FAT driver does not see these structures, and the dmsdos driver simply
1045: returns read errors - those errors just cannot confuse drivers or even
1046: make the system unusable.
1047:
1048: It can detect and correct BITFAT allocation errors - this is necessary
1049: for write access. (But the dmsdos module already does it if it is told
1050: to do so at mount time.)
1051:
1052: It detects damaged directory entries and can correct them. This is also a
1053: situation the kernel FAT driver doesn't like at all. Be warned, repairing
1054: damaged directories is a very critical job which cannot be automated
1055: completely. Some damaged directories cannot be repaired and will be converted
1056: into files instead. This gives you a chance to take a low-level disk editor
1057: and repair this by hand under Dos later (if you know how to do it). Repaired
1058: directories are saved without compression so you should be able to analyse
1059: them under Dos without further help.
1060:
1061: It also checks whether one filename is used more than once in a directory.
1062: The file can optionally be renamed. This is usually done by appending ~%d
1063: to the filename where %d is the lowest possible number not causing a
1064: conflict.
1065:
1066: It also detects lost cluster chains but does not correct them. They just
1067: use space and do nothing evil. For that, use the Dos tools that came....:)
1068:
1069:
1070: *** Currently, dmsdosfsck must be considered extremely alpha test ***
1071:
1072:
1073: It's far away from complete, but some useful things work. You *can*
1074: use dmsdosfsck with the generic fsck frontend. You can even
1075: run your usual fsck when mounting from /etc/fstab at boot time, even on
1076: CVF partitions. But that's not trivial. If you really want to do such
1077: things, take a look at the example script 'msdos.fsck-wrapper' which is
1078: suitable for the generic fsck frontend. Be sure to understand what the
1079: script does. Change it to your requirements. Then replace the link in
1080: /sbin/fsck.msdos (or /etc/fs/fsck.msdos) by a link to the script :)
1081:
1082:
1.1.1.2 ! root 1083: 13. The dmsdos Midnight Commander external filesystem utility 'mcdmsdos'
! 1084: ------------------------------------------------------------------------------
! 1085:
! 1086: Dmsdos comes with an interface utility that accepts standard Midnight
! 1087: Commander commands for reading archive files. The utility is named
! 1088: 'mcdmsdos' and is compiled during usual dmsdos compile process.
! 1089: The utility is currently read-only.
! 1090:
! 1091: Please refer to the documentation of Midnight Commander for further
! 1092: information on how to configure an external filesystem.
! 1093: You may want to write a small shell script as a wrapper around mcdmsdos
! 1094: in order to suppress output to stderr distorting the screen, e.g.
! 1095:
! 1096: #!/bin/sh
! 1097: exec /usr/local/bin/mcdmsdos $@ 2> /dev/null
! 1098:
! 1099: Furthermore, mcdmsdos can be used as a utility to quickly look at what is
! 1100: inside the CVF and to extract single files from a CVF. Today mcdmsdos even
! 1101: works in a Win32 environment, so it may be worth to learn its command line
! 1102: parameters :))
! 1103:
! 1104: mcdmsdos list <CVF_name>
! 1105:
! 1106: lists (recursively) the contents of the CVF, i.e. the names of all
! 1107: files that are in that compressed partition are printed.
! 1108:
! 1109: mcdmsdos copyout <CVF_name> <path/name_of_file> <outfile>
! 1110:
! 1111: extracts the file <path/name_of_file> from the CVF <CVF_name> and
! 1112: writes it to <outfile> (which must be a real file, not stdout).
! 1113:
! 1114: mcdmsdos copyin <CVF_name> <path/name_of_file> <infile>
! 1115:
! 1116: is expected to copy <infile> into the CVF <CVF_name> at
! 1117: <path/name_of_file> according to Midnight Commander documentation.
! 1118: This command is currently not implemented as the utility is
! 1119: read-only.
! 1120:
! 1121: If documentation of newer versions of Midnight Commander wants some more
! 1122: commands consider the respective operations to fail. I expect something
! 1123: like remove, rmdir, mkdir etc. which are missing in the current standard
! 1124: (I wrote this utility according to Midnight Commander 3.0 documentation).
! 1125: But that doesn't matter as long as mcdmsdos is read-only :)
! 1126:
! 1127:
! 1128: 14. Authors and email addresses:
1.1 root 1129: ------------------------------------------------------------------------------
1130:
1131: CVF-FAT/dmsdos is the official successor of the former dmsdos filesystem. The
1132: dmsdos filesystem was initially written from scratch by Frank Gockel, after
1133: taking a close look at the THS filesystem (a read-only doublespace fs with
1134: only DS-0-2 decompression written by Thomas Scheuermann). Stacker support
1135: and drivespace 3 'ultra' compression/decompression were added by Pavel Pisa
1136: as well as improved DS/JM compression and decompression routines. Meanwhile,
1137: it contains several parts of code that was directly provided or code that is
1138: based on the ideas from a lot of people over the net in order to fix bugs,
1139: to improve performance, and to add features.
1140:
1141: The dmsdos code is distributed under the GNU General Public Licence
1142: (see file COPYING).
1143:
1144: The dmsdos driver is currently maintained by Pavel Pisa (stacker access,
1145: SQ compression, meanwhile all other compression too) and me, Frank Gockel
1146: (rest of the code).
1147:
1148: Pavel's email address is [email protected], my email address is
1149: [email protected].
1150:
1151: If you want to contact me via email, please write in English or take a close
1152: look at the country codes in the email addresses :)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.