Hi James, thanks for getting back on this issue. I have tested this patch for over a year and it works flawlessly without any data corruption ! On such kind of drives the actual situation is just the opposite as you describe: data corruption occurs when not using this patch ! I do not agree with you: if a drive does not support Synchronize Cache command, there is no point in treating the failure as critical and by all means the failure must be ignored, as there is nothing which can be done about it and it should not be treated as a failure ! However, if you are willing to propose an alternative patch, I'd be happy to test it and report back, as long as this bug is fixed in the shortest time possible. Guido On Sun, 28/02/2021 at 08.37 -0800, James Bottomley wrote: > On Sun, 2021-02-28 at 10:01 +0100, Guido Trentalancia wrote: > > Many obsolete hard drives do not support the Synchronize Cache SCSI > > command. Such command is generally issued during fsync() calls > > which > > at the moment therefore fail with the ILLEGAL_REQUEST sense key. > > It should be that all drives that don't support sync cache also don't > have write back caches, which means we don't try to do a cache sync > on > them. The only time you we ever try to sync the cache is if the > device > advertises a write back cache, in which case the sync cache command > is > mandatory. > > I'm sure some SATA manufacturers somewhere cut enough corners to > produce an illegally spec'd drive like this, but your proposed remedy > is unviable: you can't ignore a cache failure on flush barriers which > will cause data corruption. You have to disable barriers on the > filesystem to get correct operation and be very careful about power > down. > > James > >
