Does DISMOUNT flush the cache?

[Nate Bushman]

If I send FSCTL_DISMOUNT_VOLUME to a volume's device object
without locking and unlocking, the file system will dismount and there
won't be a cache for that volume.

Since the cache is completely removed after FSCTL_DISMOUNT_VOLUME
returns success, it's obvious that this IOCTL purges the cache, but I'm not
sure if
it flushes outstanding dirty blocks before it performs the purge. Anyone
know?

When I say "flush" I mean "write dirty cached data to disk" When I say
"purge" I mean
"discard all cache information - do not flush it to disk, just get rid of
all cache
data"

I wrote a little app to test this... It writes a ton of data to a file and
then immediately
dismounts. I figured that if the dismount purges but doesn't flush, some of
the data
wouldn't have ended up on the disk. Well, every time I run the program
(with different
file sizes) all of the data ends up on the physical disk. So, so far I can
only assume
that the dismount flushes the cache AND purges the cache. I wanted to
increase the
delay between lazy writes, but I can't seem to figure out how to do this for
W2K (yeah,
I saw that www.sysinternals.com has an NT4 app that can increase the lazy
write
delay, but there's no source and I need to know this for W2K). If I can
increase the
lazy write delay, I'll be more confident of my assumption.

[Slava M. Usov]

"Nate Bushman" <nbus...@bigfoot.com> wrote in message
news:enlhDZ0TAHA.76@cppssbbsa05...

> If I send FSCTL_DISMOUNT_VOLUME to a volume's device object
> without locking and unlocking, the file system will dismount and there
> won't be a cache for that volume.
>
> Since the cache is completely removed after FSCTL_DISMOUNT_VOLUME
> returns success, it's obvious that this IOCTL purges the cache, but I'm
not
> sure if
> it flushes outstanding dirty blocks before it performs the purge. Anyone
> know?

Nate,

it's slightly late, but I found this link:

http://www.microsoft.com/ddk/IFSkit/ntupto2k.htm . Scroll down until you
find FSCTL_DISMOUNT_VOLUME. So we have an official confirmation that this
ioctl shall dismount live volumes. The "correct" implementation is up to the
FSD, though, which in most cases should be NTFS FSD. I would expect
"graceful" dismount in all cases, but that's my personal opinion.

Slava

[David Dillard]

"Nate Bushman" <nbus...@bigfoot.com> wrote in message
news:enlhDZ0TAHA.76@cppssbbsa05...
> If I send FSCTL_DISMOUNT_VOLUME to a volume's device object
> without locking and unlocking, the file system will dismount and there
> won't be a cache for that volume.
>
> Since the cache is completely removed after FSCTL_DISMOUNT_VOLUME
> returns success, it's obvious that this IOCTL purges the cache, but I'm
not
> sure if
> it flushes outstanding dirty blocks before it performs the purge. Anyone
> know?

Its up to the FSD to handle it properly. However, its a pretty safe bet
that a dismount that succeeds will flush the cache. It certainly works
properly for NTFS.

--- David

[Nate Bushman]

Thanks for the URL!! I was especially glad to find the IRP types in there
because I wanted
to play around with sending the dismount IRP directly instead of having to
do a createfile.
By the way, remember when I was asking if you needed a job? I was joking
somewhat. Really
what I was trying to imply is, "Dang man, how do you seem do know ALL the
answers?!"
Anyway Slava, I'm sure you'd be an awesome asset, but frankly our stock's
been a dog lately
and I'm not sure I'd feel comfortable trying to get anyone to come over to
work with us. Although
we are working on some pretty cool stuff. I doubt anyone with your
expertise has a hard time
finding work, but, if you really are looking, lemme know and I'll give you
some more details.

"Slava M. Usov" <stripit...@usa.net> wrote in message
news:O$wGAy#TAHA.265@cppssbbsa05...

> "Nate Bushman" <nbus...@bigfoot.com> wrote in message
> news:enlhDZ0TAHA.76@cppssbbsa05...
> > If I send FSCTL_DISMOUNT_VOLUME to a volume's device object
> > without locking and unlocking, the file system will dismount and there
> > won't be a cache for that volume.
> >
> > Since the cache is completely removed after FSCTL_DISMOUNT_VOLUME
> > returns success, it's obvious that this IOCTL purges the cache, but I'm
> not
> > sure if
> > it flushes outstanding dirty blocks before it performs the purge.
Anyone
> > know?
>

[Nate Bushman]

Thanks David. Yeah, although I've never found any explicit documentation
to say that NTFS flushes when it successfully dismounts (the documentation
for
FSCTL_LOCK_VOLUME says that if this IOCTL succeeds, it will flush the cache,
but the documentation for FSCTL_DISMOUNT_VOLUME doesn't say anything
about flushing), all of the testing that I've done indicates that NTFS DOES
flush and
then purge the cache when FSCTL_DISMOUNT_VOLUME succeeds (even if
you didn't lock the volume before dismounting it).

"David Dillard" <ddil...@usa.net> wrote in message
news:#9uEYj$TAHA.265@cppssbbsa05...

> "Nate Bushman" <nbus...@bigfoot.com> wrote in message
> news:enlhDZ0TAHA.76@cppssbbsa05...
> > If I send FSCTL_DISMOUNT_VOLUME to a volume's device object
> > without locking and unlocking, the file system will dismount and there
> > won't be a cache for that volume.
> >
> > Since the cache is completely removed after FSCTL_DISMOUNT_VOLUME
> > returns success, it's obvious that this IOCTL purges the cache, but I'm
> not
> > sure if
> > it flushes outstanding dirty blocks before it performs the purge.
Anyone
> > know?
>

[Slava M. Usov]

"Nate Bushman" <nbus...@bigfoot.com> wrote in message

news:uLxvkbA...@cppssbbsa02.microsoft.com...

[...]

> Really
> what I was trying to imply is, "Dang man, how do you seem do know ALL the
> answers?!"

Well, as some pleasant in all respects individuals here have pointed out I
just copy and paste it. That's exactly true. What said individuals will not
tell you is how I locate the place from which to copy and paste. I don't
know it, either :-)

Slava

[Jeff]

FSCTL_LOCK_VOLUME and FSCTL_DISMOUNT_VOLUME do indeed seem to
flush the cache. Just out of interest, does anyone know of anyway
to actually prevent caching happening in the first place? I
realise that this is all part of the FastIO routines in the FS
driver, but could one ask the driver or some other kernel-mode
component (like the cache manager itself even) to not do any
caching? ZwSetSystemInformation doesn't let you set the cache
managers working sets to 0; it seems you can only raise them.

Is there any way you could simply prevent caching from happening
with a filter or some undocumented interface which allows you to
turn caching on and off at your discretion? Curious...

Thanks in advance!

Jeff

--

[Slava M. Usov]

"Jeff" <10656...@CompuServe.COM> wrote in message
news:8vbnjk$2sh$1...@sshuraac-i-1.production.compuserve.com...

For the whole volume, perhaps with a FSD filter, for a particular file --
CreateFile() and FILE_FLAG_NO_BUFFERING.

Slava

[Nate Bushman]

Good idea. Thanks - I might need to do this too.

"Slava M. Usov" <stripit...@usa.net> wrote in message

news:ehRwD0xUAHA.284@cppssbbsa03...