Does anyone know what the common method of handling caching
in USB mass storage drives is? I'm unable to query any cache
mode page in several varieties.
In particular, we've got some USB hard drives that have a
"reliable" file system on them that have occasionally been
corrupted when power was killed too soon. This shouldn't
ever happen unless data is written out of order, and that
shouldn't happen unless caching is enabled. But it doesn't
have a cache mode page to use to disable caching. And the
synchronize cache command is rejected.
Is there any other reliable SCSI way to verify that data has
been completely written? Would the FUA bit on the last
write ensure that the cache is flushed, or would it only
ensure that the single write was completed?
There are no advanced SCSI-2 features in USB flash drives.
There is no write cache, therefor no reordering or mode pages.
I suspect the problem is the write was interrupted and ECC is invalid.
Are you using your OS's "dismount" feature?
"Darin Johnson" <darin@usa.net> wrote in message
news:29f9cecf-6825-4e70-8a99-32e02d0023e6@x29g2000prg.googlegroups.com...
> Does anyone know what the common method of handling caching
> in USB mass storage drives is? I'm unable to query any cache
> mode page in several varieties.
>
> In particular, we've got some USB hard drives that have a
> "reliable" file system on them that have occasionally been
> corrupted when power was killed too soon. This shouldn't
> ever happen unless data is written out of order, and that
> shouldn't happen unless caching is enabled. But it doesn't
> have a cache mode page to use to disable caching. And the
> synchronize cache command is rejected.
>
> Is there any other reliable SCSI way to verify that data has
> been completely written? Would the FUA bit on the last
> write ensure that the cache is flushed, or would it only
> ensure that the single write was completed?
>"Darin Johnson" <darin@usa.net> wrote in message
>news:29f9cecf-6825-4e70-8a99-32e02d0023e6@x29g2000prg.googlegroups.com...
>> Does anyone know what the common method of handling caching
>> in USB mass storage drives is? I'm unable to query any cache
>> mode page in several varieties.
You don't mention what operating system, etc.
but for most, there's some option for write-thru caching
of removeable drives. Except for Apple
(where disk eject is totally under program control),
most did write-immediate for floppy drives
so the logic is rather old.
>> In particular, we've got some USB hard drives that have a
>> "reliable" file system on them that have occasionally been
>> corrupted when power was killed too soon.
The question is "why was power killed too soon"?
Improper shutdown would damage ANY media:
floppy or hard drive too.
If that's unavoidable, perhaps a journaling file system
would reduce the problem?
Eric Gisin <gisin@uniserve.com> wrote:
>There are no advanced SCSI-2 features in USB flash drives.
>There is no write cache, therefor no reordering or mode pages.
>I suspect the problem is the write was interrupted and ECC is invalid.
>Are you using your OS's "dismount" feature?
I concur: why is the drive being powered down so fast
that the system is not given any notification to
"safely remove the drive" (Win-XP) or sync/unmount (Linux).
On Dec 21, 9:02 pm, je...@panix.com (Jeff Jonas) wrote:
> You don't mention what operating system, etc.
> but for most, there's some option for write-thru caching
> of removeable drives.
This is an embedded system with no OS level caching.
The reliable file system is from a vendor, and it uses
checkpointing; ie, if there's a crash it uses the most
recent checkpoint.
The OS is Nucleus, but it has very little control other than
doing the read10/write10 and I have all the source code.
> The question is "why was power killed too soon"?
> Improper shutdown would damage ANY media:
> floppy or hard drive too.
But it should have rolled back to the last properly
saved and validated checkpoint. This would be no
different from someone yanking out the USB cable
on the drive.
If "damage" means "the wrong data is written" then the
file system should recover.
> If that's unavoidable, perhaps a journaling file system
> would reduce the problem?
This file system essentially has a similar concept, but only
two checkpoint states instead of a stream of smaller
checkpoints like most journaling systems.
> Eric Gisin <gi...@uniserve.com> wrote:
> >There are no advanced SCSI-2 features in USB flash drives.
This isn't a flash drive. It's an IDE drive with a USB to IDE
adapter case around it. IDE drives do have caching and the
ability to turn it on and off.
The one part that has been discontinued used a Cypress
controller, and it had a vendor specific configuration setting
to enable mode page 8 (disabled by default). That bit comes
with the comment "if enabled, Windows will disable write
caching by default which will limit performance." That seems
to imply that they think not allowing the OS to turn off caching
is a good thing...
> >There is no write cache, therefor no reordering or mode pages.
> >I suspect the problem is the write was interrupted and ECC is invalid.
But if the ECC is invalid, the reliable file system will just revert
to the
earlier checkpoint. The only times this file system should fail
is if the writes occur out of order. To ensure that this happens
the file system issues a flush ioctl call before writing a new
checkpoint.
But that ioctl is a no-op for us because synchronize-cache isn't
accepted by the drive and we can't turn on or off caching.
The solution so far seems to be "software delays awhile before
killing power" without any hard and fast number to use for "awhile".
But that still doesn't account for the case where the customer
accidentally kicks out the power cord.
The next step I guess is to try using the FUA bit on all the writes.
Darin Johnson wrote:
> Jeff Jonas wrote:
> > Eric Gisin <gi...@uniserve.com> wrote:
> > >
> > > There are no advanced SCSI-2 features in USB flash drives.
>
> This isn't a flash drive. It's an IDE drive with a USB to IDE
> adapter case around it. IDE drives do have caching and the
> ability to turn it on and off.
If the USB converter in the case really provides no control command for
the cache to the host it is IMHO likely that it don't touch the cache
setting of the drive at all. In this case it should be possible to
remove the IDE drive from the case and disable the cache with native ATA
commands (only make sense if the drive can store the cache setup in a
nonvolatile memory).
> The one part that has been discontinued used a Cypress
> controller, and it had a vendor specific configuration setting
> to enable mode page 8 (disabled by default). That bit comes
> with the comment "if enabled, Windows will disable write
> caching by default which will limit performance." That seems
> to imply that they think not allowing the OS to turn off caching
> is a good thing...
Low end hardware must be PnP, cheap and fast. Other features seems not
really relevant for marketing today.
> [...]
> The solution so far seems to be "software delays awhile before
> killing power" without any hard and fast number to use for "awhile".
> But that still doesn't account for the case where the customer
> accidentally kicks out the power cord.
>
> The next step I guess is to try using the FUA bit on all the writes.
For SBC devices in general even if no mode pages are implemented (or if
they are disabled) the MODE SENSE command should be implemented if they
use removable media or if the DPO & FUA bits are supported for
READ/WRITE. The DEVICE-SPECIFIC PARAMETER byte of the parameter header
contains the Bit DPOFUA for SBC devices. This Bit indicates if the DPO
and FUA Bits in READ/WRITE commands are supported.
Note:
The USB/ATA converter must not implement a SBC device (SCSI peripheral
device type 00h, USB subclass code 06h). For a harddisk USB also allow
to implement the SCSI RBC command set (SCSI peripheral device type 0Eh,
USB subclass 01h). DPO and FUA Bits don't exist in the READ(10) and
WRITE(10) commands defined by RBC, not even as an option. But the MODE
SENSE(6) command and mode page 06h are mandatory for RBC devices.
Finally the SYNCHRONIZE CACHE command is mandatory neither for SBC nor
for RBC.
Result:
There is no mandatory feature for cache control that must be present in
every USB mass storage harddisk device. Your USB/ATA converter should
support at least one of the following optional SCSI features:
- SYNCHRONIZE CACHE command
- Mode page 08h using SBC command set
- Mode page 06h using RBC command set
- WRITE(10) command with FUA using SBC command set
Every option allows the host to disable or bypass the write cache. If
none of this features is implemented in your converter, you should
consider to replace it with a better one (if the cache cannot be
permanently disabled directly at the drive).
USB drives and cache mode page 
Linear Mode
