Re: [PATCHSET] libata: implement ->set_capacity()

[Zoltan Boszormenyi <zboszor@dunaweb.hu>]

Hi,

> On Thu, May 13 2010, Tejun Heo wrote:
> > Hello,
> > 
> > On 05/13/2010 06:06 PM, James Bottomley wrote:
> > > I'm not sure this is such a good interface ... it sounds very error
> > > prone for what is effectively a binary lock/unlock.
> > 
> > Well, the original block interface was like that.  It has been used as
> > binary switch tho.  The requested capacity is always ~0ULL and return
> > value smaller than the current capacity is ignored.  I'm all for
> > dropping the capacity parameter and the return value from
> > ->set_capacity() so that it just unlocks native capacity and directly
> > sets the new capacity.  Jens?
>
> Is there a valid case for setting the capacity less than the unlocked
> capacity? I would think the unlock/lock bool api is saner.
>
> -- 
> Jens Axboe
>   

I heard about a so called "short stroking", that limits a larger capacity
harddisk to say one third or one fourth of the capacity but the gains are
increased average throughput and decreased seek time. Is it possible
under Linux ATM, or do we need the patch series to correctly do it?

I know I can partition the harddisk to only use the beginning of it
to have the same gains, but I still have a question: as I read on e.g.
tomshardware.com, this is done by instructing the harddisk, not via
partitioning. Does this "short stroking" change the amount of spare
sectors available internally to SATA disks? I suppose it would and
so the harddisk would only lose some speed not actual data when
the disk starts aging. I would have more time to discover the
problem and replace the disk, no? I am only asking...

Best regards,
Zoltán Böszörményi