Non-standard partitioning schemes

NTFSD
2

Why not? This is a good idea. If you have some disk partitioning incompatible with Windows - then this is really an issue of the disk stack and not of the FSD.

FSDs know nothing on partitions. They work with volumes, and volumes have neither MBR nor GPT.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: xxxxx@attotech.com
To: Windows File Systems Devs Interest List
Sent: Tuesday, August 09, 2005 6:32 PM
Subject: [ntfsd] Non-standard partitioning schemes

Gurus,

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

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

For me, putting the LowerFilter (at SCSI CDB level) which will emulate the fake MBR table is a better idea.

The reason is that you cannot plug inside IoReadPartitionTable, you cannot plug inside the Disk driver itself, and it creates the partition device objects exactly from the information delivered by IoReadPartitionTable, which understands MBR only - well, the Ex version also understands GPT.

With UpperFilter, you will need to go with a bus filter driver which will add additional PDO children to the disk device. This seems to be a dirtier design.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: xxxxx@attotech.com
To: Windows File Systems Devs Interest List
Sent: Tuesday, August 09, 2005 9:48 PM
Subject: RE: [ntfsd] Non-standard partitioning schemes

Unfortunately I’m stuck with an existing partitioning scheme. I have looked at the storage stack and the putting a lower filter on the disk seems to be the right place to do what I need to do (since this is where IOCTL_DISK_GET_PARTITION_INFO and friends are handled). I just wanted to find out if anyone has come across this type of thing before, and if so, whether there’s a better solution.

In fact, now that I think about it, perhaps it would be better to put an upper filter on the disk, and filter the appropriate IOCTLs, as well as direct I/O to the relevant disk sectors. This seems easier to implement, but perhaps more risky…

Thanks,
Jason

xxxxx@lists.osr.com wrote on 08/09/2005 11:35:42 AM:

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 schemes
> >
> >
> >
> > Gurus,
> >
> > 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
>
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.
> com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@attotech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Just a note that this is a file systems newsgroup and not a storage group.
Try NTDEV though most of us read both. Use a filter above the mass storage
driver. You could also write a disk class driver and handle almost any
storage device. Expose the volume the same as fastfat and ntfs and your
file system will mount correctly. Get the disk class driver working first
on an empty drive with only your MBR. Then switch to a drive that contains
a full file system and see if your FSD will attach to it. Be careful after
the disk class driver is working to not damage any of the structure because
the raw file system will mount it if no one else claims it. You might need
to extend format, but if your FSD is working correctly it may keep the
standard format from running.

wrote in message news:xxxxx@ntfsd…

Unfortunately I’m stuck with an existing partitioning scheme. I have
looked at the storage stack and the putting a lower filter on the disk
seems to be the right place to do what I need to do (since this is where
IOCTL_DISK_GET_PARTITION_INFO and friends are handled). I just wanted to
find out if anyone has come across this type of thing before, and if so,
whether there’s a better solution.

In fact, now that I think about it, perhaps it would be better to put an
upper filter on the disk, and filter the appropriate IOCTLs, as well as
direct I/O to the relevant disk sectors. This seems easier to implement,
but perhaps more risky…

Thanks,
Jason

xxxxx@lists.osr.com wrote on 08/09/2005 11:35:42 AM:

> 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 schemes
> >
> >
> >
> > Gurus,
> >
> > 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
>
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.
> com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@attotech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Jeffrey,

In the past, I have seen that with ScsiPort, inquiry, read capacity,
report LINs buffers that came from psssthrough were NOT mapped in system
space with MapBuffers set to FALSE. (Of course any coming from the port
driver and class drivers were mapped.) Has this changed? If so, with
what version of the OS and/or service pack?

Thanks,

Jerry.

>>>>>
So the real story:

  1. As Jerry says, this (MapBuffers=STOR_MAP_ALL_BUFFERS) is a
    Storport bug. We?re fixing it, no ETA at this point.
  2. For non-R/W requests (INQUIRY, REPORT LUNS, MODE SENSE, etc),
    these come from either a driver (e.g., initiated by disk.sys or the port
    driver itself) or through a passthrough command. These buffers will always
    be ?mapped?. It?s conceivable that a private driver (class, filter)
    sitting on top of the port driver could pass down a user buffer and no
    guarantees on that, but I?m not aware of any such implementation. As far
    as MS port drivers are concerned, these requests can be handled in your
    miniports without setting MapBuffers. In fact for SCSIport, it?s much
    better to avoid MapBuffers unless you need to touch the R/W data buffers.
    <<<<<<