Don't overestimate durability when multiple FileStore are on same physical storage device

Bug #714955 reported by Jason Gerard DeRose on 2011-02-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Dmedia
High
Unassigned

Bug Description

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.

Changed in dmedia:
milestone: 0.5 → 0.6
Changed in dmedia:
milestone: 0.6 → 0.7
Changed in dmedia:
milestone: 0.7 → 0.8
Changed in dmedia:
milestone: 11.08 → 11.09
Changed in dmedia:
milestone: 11.09 → 11.10
Changed in dmedia:
milestone: 11.10 → 11.11
Changed in dmedia:
milestone: 11.11 → 11.12
Changed in dmedia:
milestone: 11.12 → 12.01
Changed in dmedia:
milestone: 12.01 → 12.02
Changed in dmedia:
milestone: 12.02 → 12.03
Changed in dmedia:
milestone: 12.03 → 12.04
Changed in dmedia:
milestone: 12.04 → 12.06
Changed in dmedia:
milestone: 12.06 → 12.07
Changed in dmedia:
milestone: 12.07 → 12.08
Changed in dmedia:
milestone: 12.08 → 12.09
Changed in dmedia:
milestone: 12.09 → 12.10
Changed in dmedia:
milestone: 12.10 → 12.11
Changed in dmedia:
milestone: 12.11 → 12.12
Changed in dmedia:
milestone: 12.12 → 13.01
Changed in dmedia:
milestone: 13.01 → 13.04
Changed in dmedia:
milestone: 13.04 → 13.03
Changed in dmedia:
milestone: 13.03 → 13.04
Changed in dmedia:
milestone: 13.04 → 13.05
Changed in dmedia:
milestone: 13.05 → 13.06
Changed in dmedia:
milestone: 13.06 → 13.07
Changed in dmedia:
milestone: 13.07 → 13.08
Changed in dmedia:
milestone: 13.08 → 13.09
Changed in dmedia:
milestone: 13.09 → 13.10
Changed in dmedia:
milestone: 13.10 → 13.11
Changed in dmedia:
milestone: 13.11 → 13.12
Changed in dmedia:
milestone: 13.12 → 14.01
Changed in dmedia:
milestone: 14.01 → 14.02
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers