On 10/3/14 10:39 AM, Clemens Gruber wrote: > On 10/03/2014 04:08 PM, Lukáš Czerner wrote: >> What exactly is the problem you're trying to solve ? Does it concern >> specific application ? > > It's a software to control and configure dispensing equipment in a bar. > The problem is that power is lost frequently and the only warning is the > mentioned GPIO about 1.5 to 2 seconds in advance, then the caps are drained. > This happens very often and I have to prevent it from damaging the > filesystem. > > I did not mention it before, because I was not sure if it is relevant, > but I am running Linux 3.17-rc7 on the board. > >> So what you expect to happen if the power failure happens in the >> middle of the write to the eMMC ? > > With the 1.5 second delay, I'd like to stop the application, before that > happens. > >> I'd avoid the need to deal with this at all. File system >> (journal) itself will protect you from metadata corruption (file >> system corruption). But the application has to protect it's own >> important files for data consistency (data=journal will not help >> you, nor commit=1). >> >> The usual and simple way for the application to deal with this is to >> use temporary file, fsync the changes to make sure that everything >> hit the disk and then atomically rename the file to replace the >> original. That way your file will always by in consistent state. It >> will either have the new content, or the old one, not mix of both. > > Thank you, this approach sounds good! I will change the application > accordingly. > So the only necessary step to do when the GPIO triggers, is to quit the > applications writing to the eMMC. If I use that write, fsync, rename > strategy, I guess I could even SIGKILL them. http://lwn.net/Articles/457667/ is a good overview of data persistence best practices, FWIW. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
