Re: [PATCH v2] fat: Add nobarrier to workaround the strange behavior of device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 28 Jun 2019 23:32:06 +0900 OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> wrote:

> 
> v2:
> Just cleanup, changed the place of options under comment of fat.
> 
> ---

Please be careful with the "^---$" - it denotes "end of changelog", so
I ended up without a changelog!


> There was the report of strange behavior of device with recent
> blkdev_issue_flush() position change.

A Reported-by: would be nice, but not necessary.

> The following is simplified usbmon trace.
> 
>  4203   9.160230         host -> 1.25.1       USBMS 95 SCSI: Synchronize Cache(10) LUN: 0x00 (LBA: 0x00000000, Len: 0)
>  4206   9.164911       1.25.1 -> host         USBMS 77 SCSI: Response LUN: 0x00 (Synchronize Cache(10)) (Good)
>  4207   9.323927         host -> 1.25.1       USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x00279950, Len: 240)
>  4212   9.327138       1.25.1 -> host         USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
> 
> [...]
> 
>  7323  10.202167         host -> 1.25.1       USBMS 95 SCSI: Synchronize Cache(10) LUN: 0x00 (LBA: 0x00000000, Len: 0)
>  7326  10.432266       1.25.1 -> host         USBMS 77 SCSI: Response LUN: 0x00 (Synchronize Cache(10)) (Good)
>  7327  10.769092         host -> 1.25.1       USBMS 95 SCSI: Test Unit Ready LUN: 0x00 
>  7330  10.769192       1.25.1 -> host         USBMS 77 SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
>  7335  12.849093         host -> 1.25.1       USBMS 95 SCSI: Test Unit Ready LUN: 0x00 
>  7338  12.849206       1.25.1 -> host         USBMS 77 SCSI: Response LUN: 0x00 (Test Unit Ready) (Check Condition)
>  7339  12.849209         host -> 1.25.1       USBMS 95 SCSI: Request Sense LUN: 0x00
>  
> If "Synchronize Cache" command issued then there is idle time, the
> device stop to process further commands, and behave as like no media.
> (it returns NOT_READY [MEDIUM NOT PRESENT] for SENSE command, and this
> happened on Kindle) [just a guess, the device is trying to detect the
> "safe-unplug" operation of Windows or such?]
> 
> To workaround those devices and provide flexibility, this adds
> "barrier"/"nobarrier" mount options to fat driver.

I think it would be helpful if the changelog were to at least describe
the longer-term plan which hch described.

> --- linux/fs/fat/fat.h~fat-nobarrier	2019-06-28 21:22:18.146191739 +0900
> +++ linux-hirofumi/fs/fat/fat.h	2019-06-28 23:26:04.881215721 +0900
> @@ -51,6 +51,7 @@ struct fat_mount_options {
>  		 tz_set:1,	   /* Filesystem timestamps' offset set */
>  		 rodir:1,	   /* allow ATTR_RO for directory */
>  		 discard:1,	   /* Issue discard requests on deletions */
> +		 barrier:1,	   /* Issue FLUSH command */
>  		 dos1xfloppy:1;	   /* Assume default BPB for DOS 1.x floppies */

Documentation/filesystems/vfat.txt should be updated to describe this
new option please.  And perhaps to mention that a device-level quirk should be
used in preference, if it is available.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux