[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
- From: Eric Sandeen <sandeen redhat com>
- To: Lukas Czerner <lczerner redhat com>
- Cc: Mike Snitzer <snitzer redhat com>, Christoph Hellwig <hch infradead org>, device-mapper development <dm-devel redhat com>, DarkNovaNick gmail com, linux-lvm redhat com, linux-ext4 vger kernel org, Alasdair G Kergon <agk redhat com>
- Subject: Re: [dm-devel] do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
- Date: Mon, 02 May 2011 09:47:16 -0500
On 5/2/11 8:05 AM, Lukas Czerner wrote:
> On Mon, 2 May 2011, Mike Snitzer wrote:
...
>> The blkdev_issue_discard() change you propose could be fine (mask
>> EOPNOTSUPP return if device advertises support for discards) -- though
>> Eric said we shouldn't ever say we did something when we didn't.
>
> Exactly, so we should not say that it is not supported when it is, but
> we just hit the "wrong" part of the device:) I would just very much like
> to keep the abstraction of having one consistent device underneath the
> file system and not deal with several devices, or regions with different
> behaviour in the file system itself (let the pixies underneath deal with
> that, after all not all of us are btrfs:))
I still think we need to stick with the simple rule: "EOPNOTSUPP returned for a particular bio means that it is not supported for that particular bio" - I don't know what else we can do, without creating an ambiguity...
This does, however, suck for the layer calling in to a complex device.
What is the overhead for sending discard bios down to a device that does not support it?
-Eric
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]