logo.gif (6996 bytes)

Recycled directory
Safe writing
Space efficiency

For developers
Bug reports
The people behind SFS

This page gives you an overview of what SFS is capable of.  It will also give you an idea what features we are planning to add in the near future in planned features, and what features we are considering later on.


Below you'll find a list of features which are already implemented in SFS.

  • Fast reading of directories.
  • Fast seeking, even in extremely large files.
  • Blocksizes of 512 bytes up to 32768 bytes (32 kB) are supported.
  • Supports large partitions.  The limit is about 2000 GB, but it can be more depending on the blocksize.
  • Support for partitions larger than 4 GB or partitions located (partially) beyond the 4 GB barrier on your drive.  There is support for New Style Devices (NSD) which support 64 bit access, the 64-bit trackdisk commands and SCSI direct.
  • The length of file and directory names is internally limited only by blocksize.   Limitations in the dos.library however will reduce the effective length of file and directory names to about 100 characters.
  • The size of a file in bytes is limited to slightly less than 4 GB.  Because of limitations in dos.library we will however probably not allow files larger than 2 GB, to avoid potential problems.
  • Modifying data on your disk is very safe.  Even if your system is resetted, has crashed or experienced a powerloss than your disk will not be corrupted and will not require long validation procedures before you will be able to use it again.  In the worst case you will only lose the last few modifications made to the disk.  See Safe writing for detailed information on how this works.
  • To be able to ensure that your disk never gets corrupted we use an internal caching system which keeps track of modifications before writing them to disk.  This cache has the additional benefit that creating and copying files can be a lot faster, especially if the drive used isn't very fast (ZIP & floppy drives for example).
  • There is a built-in low-level read-ahead cache system which tries to speed up small disk accesses.  This cache has as a primary purpose to speed up directory reading but also works very well to speed up files read by applications which use small buffers.
  • Disk space is used very efficiently.  See the Space efficiency page for a comparison between a few filesystems.
  • Supports notification and Examine All.
  • Supports Soft links (hard links are not supported for now).
  • Using the SFSformat command you can format your SFS partition with case sensitive or case insensitive file and directory names. Default is case insensitive (like FFS).
  • There is a special directory which contains the last few files which were deleted. See deldir.

Planned features

The list of planned features below are features which are either already in development or are very likely to be added to the filesystem in the near future.

  • Multiuser support.
  • Built-in background file and free space defragmenter.  Already the filesystem is set up in such a way to allow for easy implementation of this feature without having to do extensive scanning of the disk before the defragmenter can begin.  This means defragmenting can be done in the background and can be interrupted at any time (even by a reset, crash or power failure) without loss of data.
  • Mirroring of important filesystem administration blocks to make the filesystem more robust.

Features we are considering

The features below are either features which are very application specific or not used very often.  If there is enough demand for some of these features we will consider implementing them in the filesystem.

  • Mirroring of complete partitions.  Such a feature would not only ensure that all your data is very safe since everything is stored twice on two different drives, but it will also speed up multiple concurrent read accesses since both drives can be used to deliver data.  This feature however normally is only used on mission critical systems (like file servers) and would be of little use on systems not equipped with high speed SCSI controllers.
  • Support for striping.  To put it simply, striping can be used to distribute data to multiple drives which increases the total available bandwidth as each disk will be used simultaneously to access part of the data.  If you for example have 2 drives than with striping all odd blocks of 64 kB would be stored on drive 1, and all even blocks of 64 kB would be stored on drive 2.  A similair scheme is used with more than 2 drives.   With striping there is also an option to use one of the drives as a parity drive.   If one of the drives crashes or becomes unuseable than the data on that drive can be reconstructed using the remaining drives which ensures that your data is very safe.   However, although it may seem that striping could speed up disk accesses by a factor of 2 or more, this is usually only the case when working with very large video streams or multi user systems.  Under normal conditions you will be hard pressed to find any speed gains at all.
  • Support for hard links (soft links are already implemented).
  • The ability to extend a partition without having to copy all your data and format the partition.
  • New DOS packets.  There are lots of ways to exploit the ability of a filesystem better than is possible at the moment.  New packets are the key to this.  For example, support for paths larger than 255 characters, live directories (directories which are updated in realtime), enforcing recordlocking and many more.  This however must be a team effort and we'll need support from writers of important applications and people willing to build new interfaces to access these new abilities.

All rights reserved.
For comments, problems or questions regarding this page contact John Hendrikx.
Last updated: 17 oktober 1998.