$ConvertToNonresident

NTFSD
1

Hi Respected All

Can somebody please drop a few words what $ConvertToNonresident is all about?

Thanks in advance
Andrew

1: kd> !fileobj fffffa8032c07860

$ConvertToNonresident

Device Object: 0xfffffa803140c060 \Driver\volmgr
Vpb: 0xfffffa8031403760
Access: Write SharedRead SharedWrite

Flags: 0x40100
Stream File
Handle Created

FsContext: 0xfffff8a00342e140 FsContext2: 0x00000000
Private Cache Map: 0xfffffa8032bd5da0
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: fffffa80319d5f68
Shared Cache Map: fffffa8032bd5c30 File Offset: 0
Data at offset 0 not mapped

2

When NTFS needs to convert a file from resident to nonresident (e.g. on an extending write), it creates a file object for its own internal use so that it can interact with the cache. That is the dummy filename that NTFS uses when it creates a file object for this purpose.

Craig

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Sunday, March 2, 2014 7:20 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] $ConvertToNonresident

Hi Respected All

Can somebody please drop a few words what $ConvertToNonresident is all about?

Thanks in advance
Andrew

1: kd> !fileobj fffffa8032c07860

$ConvertToNonresident

Device Object: 0xfffffa803140c060 \Driver\volmgr
Vpb: 0xfffffa8031403760
Access: Write SharedRead SharedWrite

Flags: 0x40100
Stream File
Handle Created

FsContext: 0xfffff8a00342e140 FsContext2: 0x00000000
Private Cache Map: 0xfffffa8032bd5da0
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: fffffa80319d5f68
Shared Cache Map: fffffa8032bd5c30 File Offset: 0
Data at offset 0 not mapped

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Thank you!

Is this name used only once when resident ? non-resident conversion happens or used all the time after it for all subsequent extending writes?

4

It would be used for the lifetime of that stream file object.

When an attribute (likely the $DATA attribute, but other attributes can be moved out of the MFT record as well) is “resident” it is stored inside the MFT record, so I/O against it needs to be resolved against the MFT record itself. Non-resident means that it is stored outside the MFT record.

People who do encryption become familiar with this issue because encrypting files on NTFS that are resident can be tricky. Usually I just tell people to force the $DATA attribute to become non-resident. That works around this complication.

Tony
OSR

5

Tony,

Usually by stuffing a big enough header in the file? Or do you suggest any other trick for forcing it out of the MFT?

On 10-Mar-2014, at 5:37 am, Tony Mason wrote:
>
>


>
> It would be used for the lifetime of that stream file object.
>
> When an attribute (likely the $DATA attribute, but other attributes can be moved out of the MFT record as well) is “resident” it is stored inside the MFT record, so I/O against it needs to be resolved against the MFT record itself. Non-resident means that it is stored outside the MFT record.
>
> People who do encryption become familiar with this issue because encrypting files on NTFS that are resident can be tricky. Usually I just tell people to force the $DATA attribute to become non-resident. That works around this complication.
>
> Tony
> OSR
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

Exactly. From what I can tell, the current implementations do not convert non-resident attributes back into resident attributes (this would be an implementation issue, though and subject to change). What this does mean is that if you make sure to write it out so it doesn’t fit and then shrink it back, it remains non-resident.

There is no version of NTFS (that’s been shipped - I’m sure someone inside MS has played with various MFT record sizes) for which a 4KB data block won’t push the $DATA attribute to be non-resident in the MFT (old NTFS used 4KB MFT entries, current NTFS uses 1KB MFT entries).

Of course, one reason I like the isolation filter model for encryption is that it makes this point moot as well (since the filter owns its own view - or views - of the cache.)

Tony
OS