If quota is not enabled it is not necessery to start separate transaction for uid, gid and quota credits changes. If inode wasn't added to orphan list when it is not necessary to remove it from the list. This allow to avoid locking on per-sb s_orphan_lock mutex. Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> --- fs/ext4/inode.c | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 3996151..b498274 ...

in ext4_ext_binsearch_idx() routine, there is the following code: while (l <= r) { m = l + (r - l) / 2; if (block < le32_to_cpu(m->ei_block)) r = m - 1; else l = m + 1; } path->p_idx = l - 1; The code always runs logN iterations to get the expected extent, if 3-way comparison is used, we can save some iterations when (block == le32_to_cpu(m->ei_block)) at the first iteration. some ...

Something like this probably works, but I really REALLY would not test it on an important filesystem. :) I'm not sure it's a good idea to discard it before returning it to the prealloc pool, because it may well get re-used again quickly.... not sure if that's helpful. Just a note, I think eventually we may move to more of a batch discard in the background, because these little discards are actually quite inefficient on the hardware we've tested so far. -Eric p.s. really. Don't test ...

I think the answer is "not yet but it's being worked on" --

1) I understand that big TRIMs are better then small ones, but skipping some TRIMs completely would lead to slow but sure drive degradation as drive would have less and less spare space for wear leveling. 2) Yes, I'm aware of possible data=writeback inconsistency, but I've tried to let IO scheduler to merge and reorganize as many writes as it can, all to avoid small writes to SSD which are main cause of write amplification. 3) I'll stick with no data=writeback for the time being. I guess ...

Ok, thanks, perfect test & explanation. Well the good news is, at least it's nothing like discarding the wrong block. :) Long explanation: in ext4_free_blocks(): /* * We need to make sure we don't reuse the freed block until * after the transaction is committed, which we can do by * treating the block as metadata, below. We make an * exception if the inode is to be written in writeback mode * since writeback mode has weak data ...

can you please provide an actual version of firmware. As soon as i know X25 zeroing was disabled. Can you please post an output of your queue flags --

Well, to be honest, I'm not some programmer guy, so I doubt my skills can be of any help here. Second, unfortunately, my SSD is now my root partition (just one big sda1), so I cannot experiment with it too much. I'm not sure I understood you well about this prealloc pool - re-using mechanism, but... AFAIK, modern SSDs are using very aggressive wear-leveling algorithms. Writing two times into the same filesystem sector almost newer goes to the same hardware sector. Therefore, saving ...

BTW, it might be possible to remove the need to take t_handle_lock by converting t_outstanding_credits and t_updates to be atomic_t's, but that might have other performance impacts for other cases. This patch shouldn't cause any performance regressions because we're just removing code. As I said, I'm pretty sure it's safe but it could use more review and I should look at it again with fresh eyes, but in the meantime, it would be great if you could let us know what sort of results you get with ...

You might want to ask djwong to play with it with his nice big machine. (We don't need a big file system, but we want as many CPU's as possible, and to use his "mailserver" workload to really stress the journal. I'd recommend using barrier=0 for additional journal lock-level stress testing, and then try some forced sysrq-b reboots and then make sure that the filesystem is consistent after the journal replay.) I've since done basic two-CPU testing using xfstests under KVM, but That's ...

Hm, if these start returning EIO then maybe my patch should be modified to treat EDQUOT differently than EIO ... assuming callers can handle the return at all. In other words, make NOFAIL really just mean "don't fail for EDQUOT" -Eric --

From: From: Eric Sandeen <sandeen@redhat.com> There was a bug reported on RHEL5 that a 10G dd on a 12G box had a very, very slow sync after that. At issue was the loop in write_cache_pages scanning all the way to the end of the 10G file, even though the subsequent call to mpage_da_submit_io would only actually write a smallish amt; then we went back to the write_cache_pages loop ... wasting tons of time in calling __mpage_da_writepage for thousands of pages we would just revisit (many times) ...

Added to the ext4 patch queue, thanks. - Ted --