On Mon, Sep 23, 2013 at 10:08:08AM -0500, Eric Sandeen wrote:
> On 9/20/13 11:42 AM, David Sterba wrote:
> > The message about trim was printed unconditionally, we should check if
> > trim is supported at all.
>
> Good idea, but I wonder if there's any risk that discard(0,0) will ever
> be optimized away on the kernel side & pass unconditionally?
I hope the checks in blkdev_issue_discard() stay in the order as of now:
40 int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
41 sector_t nr_sects, gfp_t gfp_mask, unsigned long flags)
42 {
...
52
53 if (!q)
54 return -ENXIO;
55
56 if (!blk_queue_discard(q))
57 return -EOPNOTSUPP;
here it returns no matter what the arguments are, setting length to 0 is
just cautious.
59 /* Zero-sector (unknown) and one-sector granularities are the same.
*/
60 granularity = max(q->limits.discard_granularity >> 9, 1U);
61 alignment = bdev_discard_alignment(bdev) >> 9;
62 alignment = sector_div(alignment, granularity);
63
> I was thinking we could get this from blkid, but maybe not.
Possibly yes, with other information like rotational etc.
Alternatively,
/sys/block/sdx/queue/dicard_granularity > 0 means that the device
supports discard, but that's imo even more fragile than the direct
call to discard.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
