pending/posted creates?

All,

Does anyone know if there are any reasons creates get posted to worker
threads in NTFS other than for oplock breaks? In the FAT source this seems
to be the main reason.

Thanks,
Matt

Not meant to be an exhaustive list, but in my experience:

  1. The remaining stack space is below the acceptable threshold

  2. Lock that it needs cannot be acquired (“let’s post and try to get it
    again”). You can see that FAT does this if he can’t get the VCB lock.

The posting is all done by a common routine (ntfs!ntfspostrequest on my XP
target) so with a couple of “uf” listings you should be able to set
breakpoints where any create is being posted.and get an idea as to the
reasons why (caveat emptor: name of routine and reasons for posting are a
matter of implementation and are subject to change). You could also just set
a breakpoint on the routine itself, though it does get called a lot during
normal operation.

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> All,
>
> Does anyone know if there are any reasons creates get posted to worker
> threads in NTFS other than for oplock breaks? In the FAT source this
> seems
> to be the main reason.
>
> Thanks,
> Matt
>
>
>

Matthew N. White wrote:

All,

Does anyone know if there are any reasons creates get posted to worker
threads in NTFS other than for oplock breaks? In the FAT source this seems
to be the main reason.

Apologies for being an ideologue…

The filesystem reserves the right to post to a worker queue for any
reason it sees fit. The exact set of conditions will vary between
filesystems and between releases. Taking a hard dependency on the set
of reasons for a particular filesystem in a particular release creates a
very fragile design that is liable to break across releases, service
packs or hotfixes.

  • M

From FAT (create.c):

//
// Acquire exclusive access to the vcb, and enqueue the Irp if
// we didn’t get it.
//

if (!FatAcquireExclusiveVcb( IrpContext, Vcb )) {

DebugTrace(0, Dbg, “Cannot acquire Vcb\n”, 0);

Iosb.Status = FatFsdPostRequest( IrpContext, Irp );

DebugTrace(-1, Dbg, “FatCommonCreate -> %08lx\n”, Iosb.Status );
return Iosb.Status;
}

I’ve been pointing to this code for years - it’s a “real world” case in
the IRP_MJ_CREATE path that posts EARLY in create for locking reasons.
It has nothing to do with oplocks and it clearly demonstrates that
assuming IRP_MJ_CREATE is going to be synchronous (from the FSD
implementation) is a fundamentally flawed assumption.

Bottom line: IRPs may be implemented asynchronously by a driver for any
reason they choose. That’s a fundamental part of the original design;
while its been twisted into its current condition, at the heart that
assumption is still true. You should thus be prepared to receive back
STATUS_PENDING on any IRP_MJ_XXX operation.

Tony
OSR