[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: