Daniel Kiracofe writes:
>> I'm just curious - is there any active work on a squidfs ?
>> I'd like to catch up on any ideas/code people have written.
>
> The biggest problem with ext2 wrt squid is the time it takes to search
>for a filename within a directory; It does this linearly. A good squidfs
>would need to come up with another method. Perhaps just one big
>directory. Filenames could be mapped to inodes via a closed hash table.
>The only problem with that is hash collisions. Those would be horrible.
>An open hash table might be better... Squid would probably need to be
>rewritten a bit to take advantage of this fs.
> Or, maybe bypass a kernel-land fs altogether and do raw io on a
>partition, setting up the fs in user-land...
Figured that out.
Notice how squid (1.1.x) internally stores the objects in a 3d array?
Bing.. you've just trashed the need for a namespace on squidfs because you
just take a base inode, and allocate a nice big inode array after it.
Then you write a compatibility layer in teh kernel to provide a 'virtual
namespace' .. basically giving a squid-like directory hierarchy, but direct
inode access if its needed. Not lots of kernel hacking, not lots of squid
hacking.
Then you can use the filename field in the inode to store the actual OBJECT
name. So if you trash your log file, then you just have to recursively read
the directory hierarchy to get the object names, and rebuild your logfile.
I started coding the fs code into FreeBSD, but the requirement for paid work
took me away from it.. but I might have some time now to develop the idea
further.
Adrian
Received on Mon Mar 23 1998 - 22:07:56 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:39:26 MST