On Feb 23, 2014, at 12:35 PM, Vyacheslav Dubeyko wrote: > On Feb 23, 2014, at 5:26 AM, Sergei Antonov wrote: > >> Add journal replay functionality. If filesystem is mounted for read-write and >> a non-empty journal is found, the replay action will be done. The original >> behaviour of switching to read-only mode in presense of journal by default is >> retained since the driver does not support journaled metadata modification >> anyway. After an attempt to replay has been done, the mount procedure repeats >> loading volume header to get its updated state. Having performed journal replay >> we do not run a risk of stumbling on inconsistency when working with the volume, >> so this functionality adds stability, while not changing any existing behaviour. >> Mount logic in super.c is changed as conservatively as possible. >> >> The replay code checks the integrity of the whole journal before actually >> replaying sectors. If any error (e.g. checksum mismatch, invalid/misaligned >> offsets) is detected, the volume will remain unchanged and the journal will not >> be cleared. >> >> The code supports checksums for replay data in addition to checksums for header >> and lists. Checksums for data is a relatively modern feature present on volumes >> modified by modern OS X versions. >> >> Tested with: >> drives with 512 and 4K sector sizes >> default (8 MB) and custom (1 MB, 500 MB) journal sizes >> big-endian (PowerPC) and little-endian (Intel) journal byte sexes >> >> Advantages over a previously presented >> "[PATCH v3 00/15] hfsplus: introduce journal replay functionality" >> by a different author: >> support for big-endian journal >> no redundant stuff like journal initialization >> less intrusive changes >> shorter, easier to review > > I have corrected my code for big-endian support and I am ready to submit it during next several days. > I have really bad feelings about your patch because it makes sense to announce your intentions to make > such implementation if you know about efforts from another party in this direction. For me it is really > dishonest way because I spent my time for this implementation. > > I disagree with such way of submitting patch. Because it is likewise cheating, form my point of view. I can say additionally that there are many implementation tasks in HFS+ driver. And if you don't know what to do then you can simply ask about it. It makes sense to cooperate instead of foolish cheating. As far as I can judge, HFS+ driver needs in such implementation, as minimum: (1) access to resource forks is broken, currently; (2) HFS+ compressed files support (I have initial state of code); (3) richacl support; (4) full featured journalling support; (5) FITRIM support (and flash optimizations); (6) different stabilization and optimization efforts; (7) O_TMPFILE support. This is small TODO list. I think that I don't mentioned all necessary implementation in HFS+ driver. But you prefer cheating instead of cooperation in implementation by unknown reasons for me. And it is really upset me. With the best regards, Vyacheslav Dubeyko. -- 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
