It's safe to mount the LVM2 snapshot only if you use the mount option noload. This will prevent it from using the journal, which is good, No, it's not documented. It probably should be. Hopefully, mounting the snapshot without using noload _should_ fail, since the journal is already in use, but I'm not sure we have that check in place, so I don't recommend trying it on a production file system. - Ted --

I was able to verify that mounting with noload worked as advertised. I also verified that mounting w/o noload causes the mount operation to fail. The message was "failed to claim external journal device". When I unmounted the original fs so that the journal device was not in use and then tried to mount the snapshot w/o noload, the mounted snapshot was able to claim the journal. Of course I would never do that on purpose but I wanted to see what would happen. I believe this falls under the ...

I use filysystem as Set data structure to make fast checks from scripts. Of course I can make long long file and test it with grep but it's will have linear performance degradation (List), at the same time file system has efficient tree binary structures (smth. like TreeSet). So, using filesystem is the simplest way to do this efficient. Also I always have timestamps for every entry. In this usecase all files are always empty. Here is simple performance comparison: list vs ...

Hey Ted, Sorry this took so long. I've been using a fairly large pile of patches in my testing on top of -rt, and since with -rt lockstat is less useful (you don't get any of the contention data for mutexes, and the contended spinlocks are always the internal rtmutex locks), I tried to regenerate the data on something closer to plain vanilla. So I ran dbench with 2.6.33, 2.6.33 + Nick Piggin's VFS scalability patches, and 2.6.33 + Nick's patches + your state-lock patch on an 8 cpu system. ...

Yeah, that sounds right. We do have a classic thundering hurd problem when we while are draining handles from the transaction in the T_LOCKED state --- that is (for those who aren't jbd2 experts) when it comes time to close out the current transaction, one of the first things that fs/jbd2/commit.c will do is to set the transaction into T_LOCKED state. In that state we are waiting for currently active handles to complete, and we don't allow any new handles to start until the currently running ...