Defragmenter Recycled directory Safe writing Space efficiency
Up Why? Features For developers Download Bug reports Mailinglist Troubleshooting Background 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.
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.
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.
|