implementing Lazy deletion of reference counting

NTFSD
1

Hi,

Which is the best way to delay the deletion of file information context,
what I observed is that sometimes the FsContext of a file gets allocated at
the same memory address (I guess FSD’s implement lazy deletion of
FsContexts).

I think one way for this is when the reference count for a FsContext goes to
0, we need to mark it as DELETED and do not free it and when ever wanted to
add another fsctx we need to see if it;s address is already present in the
cache and if present with DELETED flag we can comapre the file name and if
the file name matches then probably we can use the same memory allocation,
if the name does not match we replace the filename.

But I wonder when to free the DELETED entry if it does not get reallocated.

Any suggestions will be helpful.

Thanks,
Kedar.

2

The lazy deletion of your contexts boils down to a final name comparison
when the node is marked as DELETED. What you can then do is have a worker
thread in the back ground and after some lifetime, say 30 seconds or less,
that the node has been marked as DELETED and not re-used, then fully delete
it from your list.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Monday, September 19, 2005 9:47 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] implementing Lazy deletion of reference counting

Hi,

Which is the best way to delay the deletion of file information context,
what I observed is that sometimes the FsContext of a file gets allocated at
the same memory address (I guess FSD’s implement lazy deletion of
FsContexts).

I think one way for this is when the reference count for a FsContext goes to

0, we need to mark it as DELETED and do not free it and when ever wanted to
add another fsctx we need to see if it;s address is already present in the
cache and if present with DELETED flag we can comapre the file name and if
the file name matches then probably we can use the same memory allocation,
if the name does not match we replace the filename.

But I wonder when to free the DELETED entry if it does not get reallocated.

Any suggestions will be helpful.

Thanks,
Kedar.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Since a FsContext is an address, just mark it deleted and put in a time
value. Then if you get the same FsContext again, you can check the filename
and if it matches, just undelete it and update anything you need. If it is
not the same filename just update it. If you need another of your contexts
and that one is old enough, you can just clean up the deleted entry and
build a new entry for the current create.

“kedar” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> Which is the best way to delay the deletion of file information context,
> what I observed is that sometimes the FsContext of a file gets allocated
> at the same memory address (I guess FSD’s implement lazy deletion of
> FsContexts).
>
> I think one way for this is when the reference count for a FsContext goes
> to 0, we need to mark it as DELETED and do not free it and when ever
> wanted to add another fsctx we need to see if it;s address is already
> present in the cache and if present with DELETED flag we can comapre the
> file name and if the file name matches then probably we can use the same
> memory allocation, if the name does not match we replace the filename.
>
> But I wonder when to free the DELETED entry if it does not get
> reallocated.
>
> Any suggestions will be helpful.
>
> Thanks,
> Kedar.
>
>