linux-kernel - Re: [PATCH] block: export SSD/non-rotational queue flag through sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 15 Jan 2009 14:45:01 -0800
From:	Grant Grundler <grundler@...gle.com>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Greg Freemyer <greg.freemyer@...il.com>,
	Tejun Heo <htejun@...il.com>, Michael Tokarev <mjt@....msk.ru>,
	Kay Sievers <kay.sievers@...y.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] block: export SSD/non-rotational queue flag through sysfs

On Thu, Jan 15, 2009 at 11:00 AM, James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
...
>> Code can test for zero/nonzero or (preferably) more fine grained.
>> e.g. "avgreadcost > 1ms" or "avgwritecost". I'm hoping this test
>> can be abstracted into a macro.
>
> Um these really have to be things we can get out of the device at boot
> time without effort (as in part of the data the device can give in a
> single command).  I'll be shot for increasing boot time so we can work
> out these parameters ...

No. The whole point is we should not care what it is at boot time.
It should be based on recent history of what is going on.
At boot time we read the partition table and we superblocks to mount
file systems.
That's fine to start with. So I don't see any need to add some synthetic test
to establish initial values.

The rest of the code should work regardless of what the values start out to be.
This is true for the previous proposed patch too when user space has
to decide what the right policy is.

>> I'm hoping longterm, the values could be "self tuning" but don't know
>> how that might work - e.g. 1 minute avg? 10 minute avg? Cost
>> of collecting/maintaining the stats? Feels like a CONFIG option.
>
> CONFIG_SLOW_YOUR_BOOT?

maybe CONFIG_AUTOTUNE_RWCOST.

thanks,
grant
--
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/