On Tue, Apr 21, 2015 at 12:48:02PM -0400, Theodore Ts'o wrote: > On Tue, Apr 21, 2015 at 11:00:12AM -0400, Theodore Ts'o wrote: > > However, if the user types ^C, or e2fsck crashes out with a call to > > fatal_error(), we *should* make sure the undo log is in a proper state > > so it can be replied. > > It looks like the current set of patches are registering an atexit() > cleanup handler, but there aren't changes to add signal handlers; is > this correct? > > In the case of e2fsck, we have signal handlers already, but many of > the other e2fsprogs programs don't have signal handlers and unless I > missed them when I did a quick scan, it looks like this patch series > doesn't add any. Correct, it does not. I hadn't made up my mind if I wanted to continue writing stuff out if one of the bad signals comes in, but for the specific case of ^C it does seem warranted. I'm also not quite sure when's a good time to install our own "default" handler ... I guess each undo io manager could install itself via sigaction and store the old pointer for calling later? WAL could be useful too, but I wouldn't want undo_io and wal_io banging around inside libext2fs together. --D > > - Ted > -- > 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 -- 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
