<div class="gmail_quote"><div>Are you seeing individual OST mount times in the 10 minute region or for all OSTs?  <br><br>Releasing the lock is more common then you think.  Both ext3, ext4 release the lock in their ext[34]_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.<br>
<br>Jeremy<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>

<br>
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?<br>

<br>
Ashley.<br>
<br>
_______________________________________________<br>
Lustre-devel mailing list<br>
<a href="mailto:Lustre-devel@lists.lustre.org">Lustre-devel@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/mailman/listinfo/lustre-devel" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-devel</a><br>
</blockquote></div><br>