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