Are you inventing your own new partitioning scheme, or trying to get NT to
understand the partitioning scheme of some other OS / storage stack?
If you’re inventing a new partitioning scheme, I suggest you don’t. If you
need to support the partitining scheme of another platform, then I believe
it is possible, but unfortunately it is beyond my knowledge. You’ll need to
examine the NT storage stack, find out which driver is responsible for
interpreting partition tables and creating partition devices for them. Then
you’ll need to implement the same thing (same IOCTLs, etc.) for your
partition scheme, and find out how to notify the volume manager that you’ve
got a volume for it.
Sorry to give such vague information.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@attotech.com
Sent: Tuesday, August 09, 2005 11:24 AM
To: Windows File Systems Devs Interest List
Subject: SPAM-LOW: RE: [ntfsd] Non-standard partitioning schemes
Yes, that is true. The problem is that the system doesn’t recognize the
existence of my partitions, because they aren’t MBR or GPT partitions. My
question is, what’s the best way to coax it into understanding this
different partition scheme?
Jason
xxxxx@lists.osr.com wrote on 08/09/2005 11:01:30 AM:
Why is this necessary? Filesystem drivers should be attached to
partitions,
not to entire disks. My understanding of the storage stack is nothing
compared to a lot of people on this list, but I believe at least this much
is true.– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@attotech.com
Sent: Tuesday, August 09, 2005 10:32 AM
To: Windows File Systems Devs Interest List
Subject: SPAM-LOW: [ntfsd] Non-standard partitioning schemesGurus,
I’m experimenting with an FSD based on Fastfat. The problem is that the
FS
uses a non-MBR, non-GPT based partitioning scheme, so when the drive is
attached, the I/O Manager doesn’t see any partitions and therefore never
sends my driver IRP_MN_MOUNT_VOLUME. (I was assuming that for unknown
partition schemes, I/O Manager would just try to mount the entire physical
disk. This does not appear to be the case.) The only solution I can
think
of to this problem is to write a lower filter for disk.sys, and fake an
MBR-style partition based on the actual partition information. This seems
a
bit extreme, however, and it would probably break if some other driver
similarly filters the disk. Is there any other approach that is safer
and/or easier to implement?TIA,
Jason