On Tue, Apr 28, 2009 at 06:23:59PM +0200, Jan Kara wrote: > Ouch... Hmm, smp_rmb() isn't completely free and mainly it's a bit > ugly and prone to errors (I'm afraid next time someone changes the > allocation code, we miss some barriers again)... so.. Maybe a stupid > idea but wouldn't it be easier to solve the online resize like: freeze > the filesystem, do all the changes required for extend, unfreeze the > filesystem? Eric suggested a helper function when reading from s_groups_count. That would take care of the code maintenance headache. One problem with using freeze/thaw is it won't work without a journal, and we do support filesystems without journals in ext4. (Probably the best solution for netbooks with crapola SSD's.) As far as smb_rmb() not being free, it's essentially free for x86/x86_64 platforms. Is it really that costly on other architectures? - 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
