Prev: [PATCH 1/1] staging: hv: Fix error checking in channel.c
Next: ftrace syscalls, PowerPC: Fixes and PowerPC raw syscall tracepoint implementation
From: Zoltan Boszormenyi on 17 May 2010 05:10 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |