Hello,

In previous Mt Fuji specification, e.g. Fuji3v100, multiple operation request/report codes were defined beside 00h and 01h. Namely this was defined:

“2h AddChange The Feature list may have added Current Features (no Features became non-Current)

3h Reset The Logical Unit has been reset.

4h Firmware Changed The Logical Unit’s microcode may have changed.

5h Inquiry change The Logical Unit’s identification information may have changed.

”

In current Mt Fuji (6) and MMC (5) specification these values are reserved as if for future use:

“2h – FFFFh Reserved -”

I believe that instead 2h to 5h need to be marked obsolete to avoid that these values are eventually redefined for a new purpose.

Also, Microsoft would need clarification about the meaning and scope of occurrence (aka condition) of the AddChange. We have observed this in existing drives (during packet writing) and we currently interpret this value in our storage driver as the media behavior may have change thus the file system volume should be checked for change before continuing to write. Notice that verifying that the volume hasn’t changed is an expensive check when actually the media hasn’t changed: the file system needs to go through all the directory entries to ensure they are still there / intact. Thus we are wondering what are the conditions which caused an AddChange to be triggered and whether we should continue to perform this expensive verification or we can safely continue our reads and writes to this media.

Please clarify when is AddChange report.

Why was this AddChange removed from the specifications eventually?

This issue is affecting work on the life file system of Vista RTM, thus we would appreciate if the committee could have a quick turnaround studying this matter.

Best regards,

David Burg

Research Software Engineering Lead

Tel.: +1 425 707 8769