Things which we think to implement in the near (or further) future:

• Setting quota to folders (would be introduced in 1.7).

• Introducing xattr - extended file attributes (will be implemented in 1.7).

• Automatic file caching (implemented in 1.6.17).

• Modify trash can so that it has directory structure.

• Support for POSIX lock.

• "Location awareness" of chunkserver - optional file mapping IP_address->location_number. As a location we understand a rack in which the chunkserver is located. The system would then be able to optimize some operations (eg. prefer chunk copy which is located in the same rack).

• Alternative mode of keeping data just for archiving purposes - keeping one copy and only adequate differences. So we would have the security of goal=4 by a disk usage of goal=2 now. Although this solution implies loss of possibility to modify such files and little decrease in reading speed.
  The solution would be similar to Double Parity RAID, but instead of:
  
  A1 A2 A3 Ap 1n
  B1 B2 B3 Bp 2n
  C1 C2 C3 Cp 3n

  
  

  we would introduce the model like:
  
  A1 A2 A3 Ap
  B1 B2 B3 Bp
  C1 C2 C3 Cp
  q1 q2 q3 qp

  
  

  where Ap-Cp are the same as in Double Parity RAID but q1 = A1 XOR B1 XOR C1, q2 = A2 XOR B2 XOR B3, etc. and qp = Ap XOR Bp XOR Cp = q1 XOR q2 XOR q3.

• Moving to trash chunks which are not "expected" by the master server (there is no relevant information about them in metadata file now, but they were saved before and possibly they may be necessary).

• Modify saving - reduce amount of version increments.

• Introducing an option "mfsbind=IP" which would allow connecting to a specified IP which consequently would cause the use of an adequate net interface.

Items are already implemented.

If you think of any new interesting feature please post it on our SourceForge Feature Request page.