Short: Smart Filesystem by John Hendrikx (©) AND Joerg Strohmayer Author: hjohn@xs4all.nl Uploader: PIK@amigo.ping.de Type: disk/misc Version: 1.193 (-> 1.93) ------------------------------------------------------------ This filesystem is BETA -- this means it is not finished. USE AT YOUR OWN RISK! ------------------------------------------------------------ For more information read the included documentation and see http://www.xs4all.nl/~hjohn/SFS. For mailingslist and new versions see http://home.wtal.de/js/ Introduction ------------ Smart Filesystem is a new filesystem for your Amiga. A filesystem's main purpose is to store files on a disk in such a way that they can be located and used quickly. How this is done is up to the filesystem. The way information is stored on your disk has a large impact on speed and space efficiency, and so these factors can vary a lot from filesystem to filesystem. Smart Filesystem was created to provide you with an alternative to the Fast Fileystem. Smart Filesystem makes more efficient use of your disk space (max speed with 512B/block!), has better performance in MOST areas and will allow for new features never seen before in an Amiga filesystem. Features -------- o Fast seeking. Even in extremely large files. o FAST reading of directories. o F A S T defragmentation routines. o Blocksizes of 512 bytes up to 32768 bytes are supported. (512 bytes for best performance, >512 bytes for partitions bigger 2000 GB) o Support for partitions larger than 4 GB or located (partially) beyond the 4 GB barrier on your drive. There is support for the New Style Devices (NSD) which support 64 bit access and the 64-bit trackdisk commands (TD64). o Supports LARGE partitions. The limit is about 2000 GB (2 TB), but it can be more depending on the blocksize (32KB/Block -> 128 TB) o The size of a file is limited to 2 GB. o The length of file names can be 107 charakters. The lenght of directory and file names can be 255 (254?) characters. o Modifying data on your disk is very safe. Even if your system is resetted, crashes or suffers from powerloss 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. o There is a built-in configurable 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. o Disk space is used very efficiently. o Supports Notification and Examine All. o Supports softlinks (hardlinks are not supported for now). o Using the SFSformat command you can format your SFS partition with case sensitive file and directory names. Default is case insensitive (like FFS). o There is a special directory which contains the last few files which were deleted. (see sfsformat.txt) To do ----- o Make sure that freeing an adminspace area cannot get overwritten by data or a new adminspace container in the same Transaction (currently this cannot occur as adminspace areas are not freed). o Only compress cachebuffer when cachebuffer needs to be reused. The performance gain could be quite incredible when this is implemented as usually buffers are compressed about 10-100x more often than uncompressed. o Node system doesn't really need the Parent pointers in their blocks. Removing them will give extra room in the Node blocks, but will also make moving Node blocks easier. [Note: The old node system is likely to be removed completely in favor of the new B+-Tree system] o Using a binary tree to link objects in a hash-chain together instead of a singly linked list. This will speed up the search time for an object by name in extremely large directories (>5000 objects). o Extending partition on the fly support (may need built-in disk optimizer). o Multiple HD support (requires special device driver). o Links. o Keep things sorted (like FFS hash chain) -- might improve speed. o Small files (less than blocksize) can be accessed directly without going through the B-Tree, since the file-header contains a pointer to the first block. Also, we might be able to keep additional information in the fileheader, as any changes to the Extents will most likely also result in a change in the file header... o Extent chains MUST have a pointer back to the fileheader -- otherwise the optimization process cannot update the data pointer in the fileheader! o Nodes still use shifts_block32 and mask_block32... Unimplemented packets --------------------- ACTION_LOCK_RECORD ACTION_FREE_RECORD ACTION_MAKE_LINK (soft links only at the moment) ACTION_WRITE_PROTECT ACTION_EXAMINE_ALL_END KNOWN BUGS ---------- o Doesn't pay attention to disk changes. C/DiskChange might help here, but disk changes are *not fully* supported yet (so be careful!). o Doesn't pay attention to write-protection (the filesystem will get confused eventually if you've write protected the disk and start writing data to it). o Not all space gets freed again if you delete all files from a disk. This is caused by the fact that the filesystem allocates parts of the disk to store its administration blocks on demand. These areas aren't freed again (but they are reused if needed!). This will be fixed eventually, but is no more than a minor inconvience at the moment. o resizing partition doesn't make it invalid if start-block remains same. We should check for this! o Insert a disk, cd to disk, remove disk, cd to SYS:. The locklist will now be non-zero the just removed disk, but the last lock (ie, when you cd-ed to the disk) will be freed... locklist probably points to dealloced memory.. FFS: FFS seems to kill the volumenode completely when the last lock is freed. -> I tried to fix this problem, but it seems impossible. When deallocating a lock which is not currently owned by a handler there are all sorts of race conditions.