MooseFS Changelog
What's new in MooseFS 1.6.26
Mar 25, 2013- The most important changes include fixed signal handling in multithreaded modules, goal and trashtime limits in mfsexport.cfg, and a simple check for downloaded metadata files.
New in MooseFS 1.6.19 (Dec 22, 2010)
- Substantial changes were introduced to the metalogger machine and metarestore tool for better integrity of the metadata.
- A scanning progress bar in CS was added.
- The master name is now resolved when a connection fails.
- A new session is created when the previous one is lost.
- Lots of other bug fixes and improvements were made.
New in MooseFS 1.6.17 (Jul 30, 2010)
- In this release we introduced an automatic data cache management.
- It is enough to upgrade just the master server (no changes in chunk servers' or clients' code were made).
- The kernel cache mechanism always has existed but up to now the cache was always cleared upon opening a file. Now MooseFS controls whether to clear it or not by checking if the file was or not modified by another client. Let's look at some scenarios.
- First scenario:
- 1. Computer A reads the file X
- 2. Computer B reads the file X
- 3. Computer A wants to read the file X - we leave the cache (the file was not changed)
- Second scenario:
- 1. Computer A reads the file X
- 2. Computer A writes to the file X
- 3. Computer A wants tor read the file X - we leave the cache (the file was changed but computer A knows about these changes)
- Third scenario:
- 1. Computer A reads the file X
- 2. Computer B writes to the file X
- 3. Computer A wants to read the file X - here we have to force to empty the cache (because changes were made by Computer B and Computer A doesn't know about them)
- In real environments first and second scenarios happen by far more often than third scenario and that’s why it is reasonable to leave the contents of the cache and gain overall system performance.
- Of course there are some mean scenarios (but they also existed before) like this one:
- 1. Computer A opens file X and reads it completely (the file stays in cache)
- 2. Computer B modifies the file X
- 3. Computer A again reads the file X (but without closing or reopening it - just moving at position 0 and rereading it)
- In this situation Computer A would get the same data as in step 1 but the same also happened in MooseFS before.
- An attribute nodatacache was also introduced which forbids to cache a file. From version 1.6.17 up files with nodatacache attribute behave like files did in older versions of MooseFS. This flag can be used with tools mfsseteattr, mfsdeleattr and mfsgeteattr.
- This flag was added preventively and probably you won't need to use it. If after some time it appears that this is really useless it will be deleted. But if you find any case / scenario which demands disabling the automatic cache mechanism please share it with us.