As mentioned in comment #2 in lp:680467, we need to be careful not to overestimate durability when there are multiple FileStore on the same physical storage device - eg, if you have two FileStore on the same hard drive, and file X is stored in both FileStore, you still only have {'copies': 1}, not {'copies': 2}
Once lp:692449 is complete, we will have the needed information in CouchDB to know when two FileStore are on the same physical device.
I think the solution is to:
1) Try to avoid having a file in two FileStore on the same device unless there is a really good reason. There can temporarily be 2 copies, say as you copy from one to the other, but the logic that picks which FileStore to use should have some good smarts on this front.
2) When a file is in two (or more) FileStore on the same device, use {'copies': 1} for one, and {'copies': 0} for the rest, like this:
"stored": {
"FLKMHJL2E2WIV4FXAIWLKSTR": {
"copies": 1,
"time": 1297061923
},
"MZZG2ZDSOQVSW2TEMVZG643F": {
"copies": 0,
"time": 1234567890
},
}
Currently the schema dictates that 'copies' be >= 1 (seemed right at the time), but this is a good reason to allow 'copies' to be zero. Another use case is when a FileStore is on a RAID0 array, as discussed in lp:714941
As far as having multiple FileStore on the same device in the first place, I want to note that there are import use cases for this, specifically having a private user store in /home/username/.dmedia and a shared store in /home/.dmedia This makes even more sense when ecryptfs home directory encryption is used. But still, we can't kid ourselves about getting more durability just because a file is in multiple stores on same device.
