thanks for the suggestions! Pray explain what you mean by ‘user friendly’.
We would need ssome methodology to use the meta data to creae incremental
backups,and ofcourse that intelligence would be in a user land service, but
as long as the driver can furnish APIs to the service we don’t care about
win32 accessible meta data.(that is, if that is what you mean by user
friendliness)
#5 has a lot of issues with deployment. On an MBR disc one can have 4
primary partitions. using up one might not be aken well. more over, resizing
partitions on XP is not easy(risk free), trying that on production customer
machines and servers could be dangerous.
Assuming that a fnite sized hard drive would require a finite sized meta
data partition, this works well till we consider that the physical hard disc
itself can be extended (the exposed LUN can be part of RAID or other
configurations).
Also, on machines which already have 4 partitions, we would actually do a
physical to logical conversion of two partitions to make space for the
hidden one and teh extended partition entry, it is not a very clean way to
go.
Also, how abt GPT discs, the solution needs to work on GPT too.
thanks
AP
On Tue, Mar 1, 2011 at 12:13 AM, Mark Roddy wrote:
> On Mon, Feb 28, 2011 at 12:55 PM, A P wrote: > > 5. Create a hidden partition and keep data there: not very user friendly. > > also we will need to resize this partition if disc size changes, so on > RAID > > kind of setup it might not work. > > This seems to be the cleanest approach. The resize problem is generic > across all implementations: if you can’t find the resources, wherever > you locate them, to resize your bitmap, you are screwed. So why pick > on 5? > > Why would the location of this data need to be ‘user friendly’? > > Mark Roddy > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other 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 >
I am sure many fo you have worked and designed on disc change tracking
drivers. As this thread says, I am in the process of designing one from the
scratch. And I don’t want to be a PITA for any other product in the market.
My concerns:
I have heard a lot of inter-op issues of volume level change tracking
filters with file system level encryptors, mostly because these drivers tend
to violate the IO path and maintain their context meta data bypassing the
file systems.
Depending on the segment ther product is targetted, handling dynamic
volumes is also a concern.
I would like your suggestions at this early design stage (from your
experiences) as to the best ways to maintain co-existance in the Windows
universe.
Which path should I take so that these inter-ops are at a minimum? Ant
pointers would be greatly appreciated.
thanks
AP
On Tue, Mar 1, 2011 at 12:38 AM, A P wrote:
> Mark, > > thanks for the suggestions! Pray explain what you mean by ‘user friendly’. > We would need ssome methodology to use the meta data to creae incremental > backups,and ofcourse that intelligence would be in a user land service, but > as long as the driver can furnish APIs to the service we don’t care about > win32 accessible meta data.(that is, if that is what you mean by user > friendliness) > > #5 has a lot of issues with deployment. On an MBR disc one can have 4 > primary partitions. using up one might not be aken well. more over, resizing > partitions on XP is not easy(risk free), trying that on production customer > machines and servers could be dangerous. > Assuming that a fnite sized hard drive would require a finite sized meta > data partition, this works well till we consider that the physical hard disc > itself can be extended (the exposed LUN can be part of RAID or other > configurations). > Also, on machines which already have 4 partitions, we would actually do a > physical to logical conversion of two partitions to make space for the > hidden one and teh extended partition entry, it is not a very clean way to > go. > > Also, how abt GPT discs, the solution needs to work on GPT too. > > thanks > > AP > > > > On Tue, Mar 1, 2011 at 12:13 AM, Mark Roddy wrote: > >> On Mon, Feb 28, 2011 at 12:55 PM, A P wrote: >> > 5. Create a hidden partition and keep data there: not very user >> friendly. >> > also we will need to resize this partition if disc size changes, so on >> RAID >> > kind of setup it might not work. >> >> This seems to be the cleanest approach. The resize problem is generic >> across all implementations: if you can’t find the resources, wherever >> you locate them, to resize your bitmap, you are screwed. So why pick >> on 5? >> >> Why would the location of this data need to be ‘user friendly’? >> >> Mark Roddy >> >> — >> NTDEV is sponsored by OSR >> >> For our schedule of WDF, WDM, debugging and other 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 >> > >