Messages in this thread | | | Date | Wed, 29 Apr 2009 11:28:38 +0200 | From | Jan Kara <> | Subject | Re: [PATCH 1/5] ext4: Avoid races caused by on-line resizing and SMP memory reordering |
| |
On Tue 28-04-09 13:14:45, Theodore Tso wrote: > 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.) Well, in non-journalling case, we could introduce a rw semaphore (read acquired / released in journal_start / journal_stop, write acquired when the fs is frozen). This might be useful for other rare cases where freezing the fs would be beneficial. But yes, if wrapping into a helper function works then that might be the easiest way to go.
> 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? I had a feeling that it's not that expensive but not quite free either on x86/x86_64 (I know even less about other archs) - it has to lock the bus, writes in local CPU caches have to be flushed, no? Probably we don't care given the size of the functions doing allocation... As an excercise I was trying to google some numbers but was not really successful, just some comments about tens of cycles in some emails...
Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR
| |