[Gllug] Thoughts on the breadth of Free Software

[Christian Smith]

salsaman uttered:

> Here's another suggestion:
>
> the C functions "open" and "fopen" are notoriously slow, because lists of 
> files within a directory are maintained as a linked list within libc. This 
> list must be traversed entry by entry until the required file can be located 
> on the disk.
>
> It seems to me there is much room for improvement here.


Not necessarily true.

FS such as XFS, JFS and ReiserFS have BTree directories. Ext3 and UFS can 
have optional hashed directory entries.

Either way, the list is not maintained by libc, certainly since 1 BSD. The 
kernel maintains the list and a also directory entry cache for commonly 
accessed files.


>
> Consider a filesystem which is contained within a single file, and is then 
> mounted loopback as a new partition. Provided write access to this partition 
> is properly serialised, pointers to the files within this partition could be 
> stored as a binary tree (offsets from the start of the partition). There 
> would be no problem with simultaneous read accesses. However any writes to 
> the partition would require locking of the binary tree table while it is 
> being updated.
>
> Such a filesystem would have many uses, one immediate one being for video 
> editing applications, where each frame can be stored as a separate file. 
> During playback, the editor is in read-only mode, and quick access to the 
> frames would lead to much smoother playback.


Actually, how about a FUSE based filesystem to implement the same? Might 
be slower than a kernel based FS, but will be much easier to develop and 
debug, and less likely to bork the kernel.



>
> Gabriel.
> http://lives.sourceforge.net
>

Christian

--
     /"\
     \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
      X                           - AGAINST MS ATTACHMENTS
     / \
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug