On Sat, 1 Sep 2018, Klaus Kusche wrote: > > The usbmon trace shows that all the preceding commands executed > > correctly. It must be the WRITE(10) which causes the problem. > > Does the trace tell why the command is refused, > and if the disk drive or the controller caused the error? It does not. My guess is that the controller is the source. > > The FUA bit could be turned on by a mount option, such as -o sync. If > > that's not the cause, I don't know what is. > > The fs is mounted "async". > > However, as I said in my initial error report, > this happens during mount while the *superblock* of the fs is written. > I think there are good reasons for writing the superblock "sync" > even when mounting the fs async: > The filesystem should be marked "in use" on the media *before* > making any other changes to the filesystem. > > Was anything changed in the ext4 mount code in 4.18? I don't know. You'd get more information if you posted that question on an ext4 mailing list rather than a USB mailing list. > Is there any chance to circumvent or work around the failing command, > or do I have to replace my 3 enclosures with that controller? Again, I don't know. In any case, the USB layer is not particularly responsible for the commands that get sent; it merely transmits that commands it receives from other parts of the kernel. However, the USB layer does set certain quirk bits which can cause those other parts to avoid sending certain commands. Perhaps your controller needs the BROKEN_FUA flag (see the existing entries in drivers/usb/storage/unusual_devs.h with that flag). Alan Stern > > Have you tried running e2fsck -f on the ext4 filesystem before mounting > > it? > > The problem occurs on all ext4 filesystems I tried, > even on newly formatted ones. > fsck says that the filesystems are clean, > and a forced fsck finds no problems.
