[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FF2DBD3.4080800@redhat.com>
Date: Tue, 03 Jul 2012 13:47:31 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Vivek Goyal <vgoyal@...hat.com>
CC: linux-kernel@...r.kernel.org, axboe@...nel.dk, snitzer@...hat.com,
martin.petersen@...cle.com, david@...morbit.com, xfs@....sgi.com,
dm-devel@...hat.com, hch@....de
Subject: Re: [dm-devel] [PATCH v2 2/3] block: reorganize rounding of max_discard_sectors
Il 03/07/2012 04:49, Vivek Goyal ha scritto:
>> > + /* Zero-sector (unknown) and one-sector granularities are the same. */
>> > + granularity = max(q->limits.discard_granularity >> 9, 1U);
>> > +
>> > /*
>> > * Ensure that max_discard_sectors is of the proper
>> > * granularity
>> > */
>> > max_discard_sectors = min(q->limits.max_discard_sectors, UINT_MAX >> 9);
>> > + max_discard_sectors = round_down(max_discard_sectors, granularity);
>> > if (unlikely(!max_discard_sectors)) {
>> > /* Avoid infinite loop below. Being cautious never hurts. */
>> > return -EOPNOTSUPP;
>> > - } else if (q->limits.discard_granularity) {
>> > - unsigned int disc_sects = q->limits.discard_granularity >> 9;
>> > -
>> > - max_discard_sectors &= ~(disc_sects - 1);
> This is kind of odd. If discard_granularity is zero, we assume that
> discards are supported and granularity is 1. But if max_discard_sectors
> is zero, we assume discards are disabled. Not sure if we should treat
> max_discard_sectors and discard_granularity in same way or not.
Yes, this keeps the same behavior as before. It is also the one that is
consistent with drivers/scsi/sd.c. sd_config_discard always sets
limits.discard_granularity and then uses limits.max_discard_sectors to
disable discards.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists