[Lustre-devel] releasing BKL in lustre_fill_super
apittman at ddn.com
Thu Nov 4 04:35:47 PDT 2010
That is per OST, it's on the outside of the times that we see but it's not uncommon. We suffer from bug 18456 still and this mainly happens when OSTs get uncomfortably full.
On 3 Nov 2010, at 20:51, Jeremy Filizetti wrote:
> Are you seeing individual OST mount times in the 10 minute region or for all OSTs?
> Releasing the lock is more common then you think. Both ext3, ext4 release the lock in their ext_fill_super and reacquire before exiting. So when Lustre does the pre mount it gets released, and when it does the real mount for ldiskfs, but after that during that first llog write when the buddy allocator is initializing I don't see where it can be getting released. I was going to try to confirm things 100% with systemtap but our the version I have doesn't seem to pick up the lustre modules (or any additionallly added ones for that matter). I don't have any easy way to upgrade it either.
> I've been thinking about this and can't make up my mind on if it's a good idea or not, we often see mount times in the ten minute region so anything we can do to speed them up is a good thing, I find it hard to believe the core kernel mount code would accept you doing this behind their back though and I'd be surprised if it worked.
> Then again - when we were discussing this yesterday is the mount command *really* holding the BKL for the entire duration? Surely if this lock is being held for minutes we'd notice this in other ways because other kernel paths that require this lock would block?
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
More information about the lustre-devel