Martin Langhoff <martin.langh...@gmail.com> writes: > Manuel Kaufmann has been looking at SL#394, and looking at the bug > report, it struck me that it was reported backwards. I would have > written: "I filled up my disk and it knocked the system out, Sugar > would not start again, etc. Oh, btw, it was with Browse".
I agree. Every single mishandling of ENOSPC is a bug in the affected piece of software and should be fixed. However, there's a lot of broken software (including Sugar) out there that doesn't always do the right thing, often resulting in data loss (because files are updated in-place). And there will always be new software that's broken in this regard. It's the responsibility of system designers to reduce the risk of this happening by avoiding an ENOSPC situation wherever reasonably possible. Browse in particular is a very good candidate for avoiding ENOSPC. Usually the user is not going to be interested in a partial download and the file size is known in advance. It doesn't make sense to even start a download we already know to never complete successfully. Similarly, the data store should take care to leave some free space. Maybe even some heuristic that somehow rejects easy-to-regenerate entries earlier than others, if we can come up with a good enough one. [...] > I artificially filled up / with dd until barely 1MB was remaining, > then experimented with filling it up completely, then leaving a few K > free and saving stuff. Yes, I fully expect it to break left and right, like it always breaks in situations that are somewhat on the side of the road. We only test the "good" cases and a few failure scenarios the patch author thinks about (if any). There are no systematic tests that cover the less common failure modes. We don't even have a list of scenarios that we care about. We don't do system design where these kinds of things are considered. [...] > - Next boot, my Journal was gone. Actually, it's not gone, I can see > the files in ~/.sugar/default/datastore, but it is corrupt or [...] Sounds like SL#2317 [1], as Gonzalo already pointed out. Sascha [1] https://bugs.sugarlabs.org/ticket/2317 -- http://sascha.silbe.org/ http://www.infra-silbe.de/
pgp5qvDGyJJgl.pgp
Description: PGP signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel