On 6/6/11 9:32 AM, Amir G. wrote: > On Mon, Jun 6, 2011 at 4:08 PM, Lukas Czerner <lczerner@xxxxxxxxxx> wrote: >> On Mon, 9 May 2011, amir73il@xxxxxxxxxxxxxxxxxxxxx wrote: >>> >>> MERGING >>> ------- >>> These patches are based on Ted's current master branch + alloc_semp removal >>> patches. Although the alloc_semp removal is an independent (and in my eyes >>> a good) change, it is also required by snapshot patches, to avoid circular >>> locking dependency during COW allocations. >>> >>> Merging with Allison's punch holes patches should be straight forward, since >>> the hard part, namely Yongqiang's split extent refactoring patches, was >>> already merged by Ted. >>> >>> Merging with Ted's big alloc patches is going to be a bit more challenging, >>> since big alloc patches make a lot of renaming and refactoring. However, >>> since has_snapshots and big_alloc features will never work together, >>> at least testing the code together is not a big concern. >> >> Hi Amir, >> >> what is the reason for the snapshots to never work with big_alloc ? Just >> out of curiosity. >> > > For one reason, a snapshot file format is currently an indirect file > and big_alloc > doesn't support indirect mapped files. > I am not saying it cannot be done, but if it does, there would be > several obstacles > to cross. I know I'm kind of just throwing a bomb out here, but I am very concerned about the ever-growing feature (in)compatibility matrix in ext4. Take for example dioread_nolock caveats: "However this does not work with nobh option and the mount will fail. Nor does it work with data journaling and dioread_nolock option will be ignored with kernel warning. Note that dioread_nolock code path is only used for extent-based files." If ext4 matches the lifespan of ext3, in 10 years I fear that it will look more like a collection of various individuals' pet projects, rather than any kind of well-designed, cohesive project. How long can we really keep adding features which are semi- or wholly- incompatible with other features? Consider this a cry in the wilderness for less rushed feature introduction, and a more holistic approach to ext4 design... -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