Re: configurable discard parameters

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

 



Still, I wonder if the kernel should allow the user to configure the
real granularity and send ATA commands that are rounded off by it
(which works just like --step in blkdiscard). For example,

(64 * 65535) % 8 = 0

but

65535 % 8 = 7

So the block count limit for the ATA commands would be 65535 - (65535
% real_gran) per range.


Also, by experimenting on my SanDisk Extreme USB with hdparm TRIM and
hexdump, I can see that the maximum block/sector allowed to be
discarded per ATA command is 65536, inspite of the payload size. I
don't know whether the USB bridging or the way hdparm does TRIM
matters, but it seems that some devices can't really handle limit like
0x3fffc0 blocks.

So I still think that the kernel should allow users to configure
limits that can make libata send reliable ATA TRIM commands.

On 23 June 2015 at 04:57, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote:
>
> Tom> So it actually tells. And I hope that the kernel wouldn't "falsify"
> Tom> anything for devices which do provide some VPD(s). : \
>
> SATA doesn't have VPDs.
>

I know now, that's why I think it's "alright" for libata to do so. I
just don't know whether the kernel would tamper with them for devices
like USB or real SCSI drives.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux