On Tue, 2009-08-04 at 14:20 -0400, John Stoffel wrote: > >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@xxxxxx> writes: > > Valdis> On Tue, 04 Aug 2009 12:27:48 EDT, Eric Paris said: > >> On Tue, 2009-08-04 at 17:09 +0100, Tvrtko Ursulin wrote: > >> > Would it make more sense to deny on timeouts and then evict? I am thinking it > >> > would be more secure with no significant drawbacks. Also for usages like HSM > >> > allowing it without data being in place might present wrong content to the > >> > user. > >> > >> I'd be willing to go that route as long as noone else complains. > > Valdis> Yes, in my world, "deny on timeout and evict" is the better > Valdis> design decision. For an HSM, you'd rather have a > Valdis> quick-and-ugly death on a failed file open than an app > Valdis> accidentally reading the HSM's stub data thinking it's the > Valdis> original data. > > Speaking as somone who is working slowly to deploy an HSM service, one > thing to note is that when you *do* see the stub file contents, you > know that your HSM is busted somehow. > > How will fanotify deal with this issue? Sorry, I haven't paid enough > attention to this thread though I know I should since it's up my $WORK > alley. fanotify doesn't explicitly deal with it at all. If the HSM implemented as a fanotify listener starts to misbehave and not respond, processes will start to get EACCES. If it misses 10 in a row it'll be evicted and processes will start to see the stubs. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
