Re: Filesystem ideas
Date: Sat, 22 Jul 2000 09:50:01 +0200
From: Tomasz Wegrzanowski <maniek@beer.com>
I think these filesystem improvements would be useful :
1)
Directory attribute SIGNIFICANT_FILES_ORDER.
If `ls' or CUI filesystem explorer would find this flag on directory,
or if shell would expand globs over this directory, and they would
find that flag, they would not sort the result, but give it to user as-is.
Example purpose: audio CDs
`ls -f' already does this :-)
2)
Multicast files.
This is often useful to cast the same to many files.
It would be nice if GNU/Hurd suported this.
Interface could be:
/* new fd, -1 error */ int multicast_new (int normal_fd);
/* 0 ok, -1 errror */ int multicast_add (int mc_fd, int normal_fd);
Example purpose: console+log output, servers optimalization
It shouldn't be too difficult to implement a translator that does
something like that. I Wonder if Mach port sets could be of any
assistence here. But I don't think this is a standard feature that
the file system should implement. By all means, go ahead and
implement it if you think it's useful.
3)
Filesystem Object (File/Directory/etc) attribute DYNAMIC_CONTENT.
This would mean you CAN get file size, directory content, etc.,
but this is non-trivial for them to raport it and
should be done only on purpose.
Example purpose: /proc/*, files mounted over ftpfs,
unmouned /mnt/* filesystems
Sorry I don't see the need for this. You can check whether a node is
translated. If it is the content usually is pretty much dynamic.
4)
system call like this
size_t transfer_data (int file_in, int file_out, size_t size);
There is such thing on both newer Linuces and NT.
Example purpose: major optimalization on multi-server environment
(huge memory usage is GNU/Hurd's biggest
performance problem) servers optimalization
I believe Mach's architecture should make this largely unecessary, but
I'm not sure. Some investigation would be necessary.
Are they very problematic ?
I don't think there's anything that prevents you from doing things
like that.
Anyone working on something like that ?
As far as I known nobody is working on things like this.
Mark
Reply to: