block: export SSD/non-rotational queue flag through sysfs

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

Quoted 6 lines · Bartlomiej Zolnierkiewicz

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

I agree with that, was actually planning on doing that myself.

Review static ssize_t queue_nomerges_store(stru · line 174

Quoted 10 lines

(quoted diff) +1 -1

@@ -146,8 +167,8 @@ static ssize_t queue_nomerges_store(stru
 		queue_flag_set(QUEUE_FLAG_NOMERGES, q);
 	else
 		queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
-
 	spin_unlock_irq(q->queue_lock);
+
 	return ret;
 }
 

Hmm?

Quoted 4 lines

(quoted diff) +0 -0

@@ -210,6 +231,12 @@ static struct queue_sysfs_entry queue_hw
 	.show = queue_hw_sector_size_show,
 };
 

Review static struct queue_sysfs_entry queue_hw · line 239

Quoted 6 lines

(quoted diff) +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+	.attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+	.show = queue_nonrot_show,
+	.store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

Quoted 10 lines · Jens Axboe

Quoted 6 lines · Bartlomiej Zolnierkiewicz

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

I agree with that, was actually planning on doing that myself.

Quoted 12 lines

block/blk-sysfs.c static ssize_t queue_nomerges_store(stru · line 174

Quoted 10 lines

block/blk-sysfs.c +1 -1

@@ -146,8 +167,8 @@ static ssize_t queue_nomerges_store(stru
 		queue_flag_set(QUEUE_FLAG_NOMERGES, q);
 	else
 		queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
-
 	spin_unlock_irq(q->queue_lock);
+
 	return ret;
 }
 

Hmm?

This is just a "bonus". :)

Quoted 4 lines

Quoted 4 lines

block/blk-sysfs.c +0 -0

@@ -210,6 +231,12 @@ static struct queue_sysfs_entry queue_hw
 	.show = queue_hw_sector_size_show,
 };
 

Quoted 9 lines

block/blk-sysfs.c static struct queue_sysfs_entry queue_hw · line 239

Quoted 6 lines

block/blk-sysfs.c +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+	.attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+	.show = queue_nonrot_show,
+	.store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

Yeah...

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH v2] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

As a bonus do a minor CodingStyle fixup in queue_nomerges_store().

Suggested-by Alan Cox <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

---
 block/blk-sysfs.c |   30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

Index: b/block/blk-sysfs.c
===================================================================

block/blk-sysfs.c +28 -1

@@ -130,6 +130,27 @@ static ssize_t queue_max_hw_sectors_show
 	return queue_var_show(max_hw_sectors_kb, (page));
 }
 
+static ssize_t queue_nonrot_show(struct request_queue *q, char *page)
+{
+	return queue_var_show(blk_queue_nonrot(q), page);
+}
+
+static ssize_t queue_nonrot_store(struct request_queue *q, const char *page,
+				  size_t count)
+{
+	unsigned long nm;
+	ssize_t ret = queue_var_store(&nm, page, count);
+
+	spin_lock_irq(q->queue_lock);
+	if (nm)
+		queue_flag_set(QUEUE_FLAG_NONROT, q);
+	else
+		queue_flag_clear(QUEUE_FLAG_NONROT, q);
+	spin_unlock_irq(q->queue_lock);
+
+	return ret;
+}
+
 static ssize_t queue_nomerges_show(struct request_queue *q, char *page)
 {
 	return queue_var_show(blk_queue_nomerges(q), page);

@@ -146,8 +167,8 @@ static ssize_t queue_nomerges_store(stru
 		queue_flag_set(QUEUE_FLAG_NOMERGES, q);
 	else
 		queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
-
 	spin_unlock_irq(q->queue_lock);
+
 	return ret;
 }
 

@@ -210,6 +231,12 @@ static struct queue_sysfs_entry queue_hw
 	.show = queue_hw_sector_size_show,
 };
 
+static struct queue_sysfs_entry queue_nonrot_entry = {
+	.attr = {.name = "non-rotational", .mode = S_IRUGO | S_IWUSR },
+	.show = queue_nonrot_show,
+	.store = queue_nonrot_store,
+};
+
 static struct queue_sysfs_entry queue_nomerges_entry = {
 	.attr = {.name = "nomerges", .mode = S_IRUGO | S_IWUSR },
 	.show = queue_nomerges_show,

Quoted 115 lines · Bartlomiej Zolnierkiewicz

Quoted 10 lines · Jens Axboe

Quoted 6 lines · Bartlomiej Zolnierkiewicz

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

I agree with that, was actually planning on doing that myself.

Quoted 12 lines

block/blk-sysfs.c static ssize_t queue_nomerges_store(stru · line 174

Quoted 10 lines

block/blk-sysfs.c +1 -1

@@ -146,8 +167,8 @@ static ssize_t queue_nomerges_store(stru
 		queue_flag_set(QUEUE_FLAG_NOMERGES, q);
 	else
 		queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
-
 	spin_unlock_irq(q->queue_lock);
+
 	return ret;
 }
 

Hmm?

This is just a "bonus". :)

Quoted 4 lines

Quoted 4 lines

block/blk-sysfs.c +0 -0

@@ -210,6 +231,12 @@ static struct queue_sysfs_entry queue_hw
 	.show = queue_hw_sector_size_show,
 };
 

Quoted 9 lines

block/blk-sysfs.c static struct queue_sysfs_entry queue_hw · line 239

Quoted 6 lines

block/blk-sysfs.c +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+	.attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+	.show = queue_nonrot_show,
+	.store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

Yeah...

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH v2] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

As a bonus do a minor CodingStyle fixup in queue_nomerges_store().

Suggested-by Alan Cox <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

---
 block/blk-sysfs.c |   30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

Index: b/block/blk-sysfs.c
===================================================================

block/blk-sysfs.c +28 -1

@@ -130,6 +130,27 @@ static ssize_t queue_max_hw_sectors_show
 	return queue_var_show(max_hw_sectors_kb, (page));
 }
 
+static ssize_t queue_nonrot_show(struct request_queue *q, char *page)
+{
+	return queue_var_show(blk_queue_nonrot(q), page);
+}
+
+static ssize_t queue_nonrot_store(struct request_queue *q, const char *page,
+				  size_t count)
+{
+	unsigned long nm;
+	ssize_t ret = queue_var_store(&nm, page, count);
+
+	spin_lock_irq(q->queue_lock);
+	if (nm)
+		queue_flag_set(QUEUE_FLAG_NONROT, q);
+	else
+		queue_flag_clear(QUEUE_FLAG_NONROT, q);
+	spin_unlock_irq(q->queue_lock);
+
+	return ret;
+}
+
 static ssize_t queue_nomerges_show(struct request_queue *q, char *page)
 {
 	return queue_var_show(blk_queue_nomerges(q), page);

@@ -146,8 +167,8 @@ static ssize_t queue_nomerges_store(stru
 		queue_flag_set(QUEUE_FLAG_NOMERGES, q);
 	else
 		queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
-
 	spin_unlock_irq(q->queue_lock);
+
 	return ret;
 }
 

@@ -210,6 +231,12 @@ static struct queue_sysfs_entry queue_hw
 	.show = queue_hw_sector_size_show,
 };
 
+static struct queue_sysfs_entry queue_nonrot_entry = {
+	.attr = {.name = "non-rotational", .mode = S_IRUGO | S_IWUSR },
+	.show = queue_nonrot_show,
+	.store = queue_nonrot_store,
+};
+
 static struct queue_sysfs_entry queue_nomerges_entry = {
 	.attr = {.name = "nomerges", .mode = S_IRUGO | S_IWUSR },
 	.show = queue_nomerges_show,

@@ -229,6 +256,7 @@ static struct attribute *default_attrs[]
 	&queue_max_sectors_entry.attr,
 	&queue_iosched_entry.attr,

block/blk-sysfs.c static struct attribute *default_attrs[] · line 262

Quoted 5 lines

block/blk-sysfs.c +1 -0

 	&queue_hw_sector_size_entry.attr,
+	&queue_nonrot_entry.attr,
 	&queue_nomerges_entry.attr,
 	&queue_rq_affinity_entry.attr,
 	NULL,

Almost all block devices might find this useful. Ought not this flag to be in the block layer appearing under /sys/block/<dev>?

Quoted 10 lines · Jens Axboe

Quoted 6 lines · Bartlomiej Zolnierkiewicz

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

I agree with that, was actually planning on doing that myself.

Quoted 12 lines

block/blk-sysfs.c static ssize_t queue_nomerges_store(stru · line 174

Quoted 10 lines

block/blk-sysfs.c +1 -1

@@ -146,8 +167,8 @@ static ssize_t queue_nomerges_store(stru
 		queue_flag_set(QUEUE_FLAG_NOMERGES, q);
 	else
 		queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
-
 	spin_unlock_irq(q->queue_lock);
+
 	return ret;
 }
 

Hmm?

This is just a "bonus". :)

Review

Quoted 6 lines · Bartlomiej Zolnierkiewicz

(quoted diff) +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+     .attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+     .show = queue_nonrot_show,
+     .store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

Quoted 11 lines · Jens Axboe

Review

Quoted 6 lines · Bartlomiej Zolnierkiewicz

(quoted diff) +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+     .attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+     .show = queue_nonrot_show,
+     .store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

What's that negation good for? Can't we just have "rotational", like we have "removable" and not "non-removable"? :)

Quoted 10 lines · Kay Sievers

Quoted 9 lines · Jens Axboe

Review

Quoted 6 lines · Bartlomiej Zolnierkiewicz

(quoted diff) +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+     .attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+     .show = queue_nonrot_show,
+     .store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

Quoted 2 lines

What's that negation good for? Can't we just have "rotational", like we have "removable" and not "non-removable"? :)

Non-rotational is the term typically used, since rotational is the norm (still). So I think the negation actually makes sense in this case :-)

Quoted 14 lines · Jens Axboe

Quoted 12 lines · Kay Sievers

Quoted 9 lines · Jens Axboe

Review

Quoted 6 lines · Bartlomiej Zolnierkiewicz

(quoted diff) +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+     .attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+     .show = queue_nonrot_show,
+     .store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

What's that negation good for? Can't we just have "rotational", like we have "removable" and not "non-removable"? :)

Quoted 2 lines

Non-rotational is the term typically used, since rotational is the norm (still). So I think the negation actually makes sense in this case :-)

You used the word "still" yourself. I mean, in 5 years SSD will be more common than rotational media, and "the norm" will be !rotational.. So let's name them correctly and uniformly from the beginning.. ;)

Quoted 14 lines · Jens Axboe

Quoted 12 lines · Kay Sievers

Quoted 9 lines · Jens Axboe

Review

Quoted 6 lines · Bartlomiej Zolnierkiewicz

(quoted diff) +6 -0

+static struct queue_sysfs_entry queue_nonrot_entry = {
+     .attr = {.name = "nonrot", .mode = S_IRUGO | S_IWUSR },
+     .show = queue_nonrot_show,
+     .store = queue_nonrot_store,
+};
+

Lets please use a better name for export reasons, non-rotational is a lot better. Nobody will know what nonrot means :-)

What's that negation good for? Can't we just have "rotational", like we have "removable" and not "non-removable"? :)

Quoted 2 lines

Non-rotational is the term typically used, since rotational is the norm (still). So I think the negation actually makes sense in this case :-)

You used the word "still" yourself. I mean, in 5 years SSD will be more common than rotational media, and "the norm" will be !rotational.. So let's name them correctly and uniformly from the beginning.. ;)

I'm afraid that's pretty much marketing coolaid. Rotational storage will dominate for the forseeable future: just do a simple back of the envelope calculation:

Hello,

Quoted 3 lines · James Bottomley

I'm afraid that's pretty much marketing coolaid. Rotational storage will dominate for the forseeable future: just do a simple back of the envelope calculation:

Or just compare prices per byte of memory, flash and rotation disk. They haven't had changed too much during last several years. Secondary storage which is only slightly cheaper than the primary storage doesn't have much chance of flying high and far.

Thanks.

--
tejun

Quoted 2 lines

Or just compare prices per byte of memory, flash and rotation disk. They haven't had changed too much during last several years.

Quoted 3 lines

Secondary storage which is only slightly cheaper than the primary storage doesn't have much chance of flying high and far. tejun

Have you seen the new pricing Samsung has announced for their 3rd generation SSD. It is about 1/3 of the Intel' SSD price if I recall correctly and the performance is approaching Intel's from what I've seen.

I've been talking to the OpenHSM (Hierachical Storage Manager) team about their project. They are working on getting the logic in place now to move data blocks from one class of storage to another while leaving the filesystem itself un-affected from the users perspective.

http://code.google.com/p/fscops/

They have a very long way to go with their code/project, but it is conceptually similar to the ext4_defrag patch that already exists. The big difference is the data block allocation algorithm will have to be totally different.

If and when that get their code done, I would love to have 500 GB of SSD teamed with several TB of rotational HDD and have the HSM move my files between fast SSD and slow rotational. I typically know which datasets I will be working with heavily, so even a simple user space tool that would let me adjust which tier of storage my files were sitting on would suffice.

Quoted 14 lines · Tejun Heo

Hello,

Quoted 3 lines · James Bottomley

I'm afraid that's pretty much marketing coolaid. Rotational storage will dominate for the forseeable future: just do a simple back of the envelope calculation:

Or just compare prices per byte of memory, flash and rotation disk. They haven't had changed too much during last several years. Secondary storage which is only slightly cheaper than the primary storage doesn't have much chance of flying high and far.

Thanks.

Quoted 2 lines

--
tejun

Have you seen the new pricing Samsung has announced for their 3rd generation SSD. It is about 1/3 of the Intel' SSD price if I recall correctly and the performance is approaching Intel's from what I've seen.

I've been talking to the OpenHSM (Hierachical Storage Manager) team about their project. They are working on getting the logic in place now to move data blocks from one class of storage to another while leaving the filesystem itself un-affected from the users perspective.

http://code.google.com/p/fscops/

They have a very long way to go with their code/project, but it is conceptually similar to the ext4_defrag patch that already exists. The big difference is the data block allocation algorithm will have to be totally different.

If and when that get their code done, I would love to have 500 GB of SSD teamed with several TB of rotational HDD and have the HSM move my files between fast SSD and slow rotational. I typically know which datasets I will be working with heavily, so even a simple user space tool that would let me adjust which tier of storage my files were sitting on would suffice.

Right, this is the flash cache idea that's been floating around for a while. It's even been suggested as a way of avoiding the IDE barrier flush penalties. I think Seagate went as far as making hybrid drives that were a large flash cache backed by rotational storage.

On Thu, Jan 15, 2009 at 8:06 AM, James Bottomley
<[email protected]> wrote:
...

Quoted 4 lines

Right, this is the flash cache idea that's been floating around for a while. It's even been suggested as a way of avoiding the IDE barrier flush penalties. I think Seagate went as far as making hybrid drives that were a large flash cache backed by rotational storage.

"inline" RAM caches were implemented 10+ years ago for SCSI devices to avoid seek *and* rotational delay penalties. These were transperent SCSI devices that would cache and prefetch content from disks. For the given dataset size, the seek cost was effectively zero. This is mostly true today for high-end disk arrays which have large RAM front-end's (TB) and very smart data placement strategies (reduced seek).

Back to the bikeshed painting: I prefer two flags: "AVGREADCOST" and "AVGWRITECOST as the flag. This isn't just about seek. Rotational delay @7200 RPM is 8.3ms. Making both non-zero implies rotational media. Different devices have different read and write characteristics. Flash typically has a much higher write cost than read cost. Disks (because of WCE) can be the opposite.

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.

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.

Quoted 3 lines

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 ...

Quoted 3 lines

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?

On Thu, Jan 15, 2009 at 11:00 AM, James Bottomley
<[email protected]> wrote:
...

Quoted 8 lines

Quoted 3 lines

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.

OK, so they could be calculated on the fly in the elevators, I suppose. But what would the value be? Right now we use the nonrotational flag to basically not bother with plugging (no point if no seek penalty) on certain events where we'd previously have waited for other I/O to join. But that's really a seek penalty parameter rather than the idea of read or write costing (although the elevators usually track these dynamically anyway ... as part of the latency calculations but not explicitly).

Quoted 7 lines · James Bottomley

OK, so they could be calculated on the fly in the elevators, I suppose. But what would the value be? Right now we use the nonrotational flag to basically not bother with plugging (no point if no seek penalty) on certain events where we'd previously have waited for other I/O to join. But that's really a seek penalty parameter rather than the idea of read or write costing (although the elevators usually track these dynamically anyway ... as part of the latency calculations but not explicitly).

... not bother with plugging (no point if no seek penalty) ...

I thought there was considerable advantage to plugging writes (in case they turn out to be adjacent) on current and older generations of non-rotational storage?

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 8 lines · James Bottomley

OK, so they could be calculated on the fly in the elevators, I suppose. But what would the value be? Right now we use the nonrotational flag to basically not bother with plugging (no point if no seek penalty) on certain events where we'd previously have waited for other I/O to join. But that's really a seek penalty parameter rather than the idea of read or write costing (although the elevators usually track these dynamically anyway ... as part of the latency calculations but not explicitly).

... not bother with plugging (no point if no seek penalty) ...

I thought there was considerable advantage to plugging writes (in case they turn out to be adjacent) on current and older generations of non-rotational storage?

Quoted 10 lines · Hugh Dickins

Quoted 8 lines · James Bottomley

OK, so they could be calculated on the fly in the elevators, I suppose. But what would the value be? Right now we use the nonrotational flag to basically not bother with plugging (no point if no seek penalty) on certain events where we'd previously have waited for other I/O to join. But that's really a seek penalty parameter rather than the idea of read or write costing (although the elevators usually track these dynamically anyway ... as part of the latency calculations but not explicitly).

Quoted 5 lines

... not bother with plugging (no point if no seek penalty) ...

I thought there was considerable advantage to plugging writes (in case they turn out to be adjacent) on current and older generations of non-rotational storage?

Heh, you get as many answers to that one as their are SSD manufacturers. However, the consensus seems to be that all MLC and SLC flash has a RAID like architecture internally, thus it can actually be *faster* if you send multiple commands (each area of the RAID processes independently). Of course, you have to be *able* to send multiple commands, so the device must implement TCQ/NCQ, but if it does, it's actually beneficial *not* to wait even if the requests are adjacent.

However, the reason the nonrotational flag is set from user space is precisely so if we do find an SSD that has this property, we can just not set the nonrotational queue flag.

Quoted 26 lines · James Bottomley

Quoted 10 lines · Hugh Dickins

Quoted 8 lines · James Bottomley

OK, so they could be calculated on the fly in the elevators, I suppose. But what would the value be? Right now we use the nonrotational flag to basically not bother with plugging (no point if no seek penalty) on certain events where we'd previously have waited for other I/O to join. But that's really a seek penalty parameter rather than the idea of read or write costing (although the elevators usually track these dynamically anyway ... as part of the latency calculations but not explicitly).

Quoted 5 lines

... not bother with plugging (no point if no seek penalty) ...

I thought there was considerable advantage to plugging writes (in case they turn out to be adjacent) on current and older generations of non-rotational storage?

Heh, you get as many answers to that one as their are SSD manufacturers. However, the consensus seems to be that all MLC and SLC flash has a RAID like architecture internally, thus it can actually be *faster* if you send multiple commands (each area of the RAID processes independently). Of course, you have to be *able* to send multiple commands, so the device must implement TCQ/NCQ, but if it does, it's actually beneficial *not* to wait even if the requests are adjacent.

Quoted 4 lines

However, the reason the nonrotational flag is set from user space is precisely so if we do find an SSD that has this property, we can just not set the nonrotational queue flag.

Not all non-rotational SSDs are created equal (as Intel said).

Some SSD performs better as the I/O queue length increase, while others not. For SSD with scalable queueing performance, it might be better to allow multiple discrete I/Os.

I'm not sure if "non-rotational" is well suited for tuning the behavior of elevator merging.

Quoted 8 lines · James Bottomley

OK, so they could be calculated on the fly in the elevators, I suppose. But what would the value be? Right now we use the nonrotational flag to basically not bother with plugging (no point if no seek penalty) on certain events where we'd previously have waited for other I/O to join. But that's really a seek penalty parameter rather than the idea of read or write costing (although the elevators usually track these dynamically anyway ... as part of the latency calculations but not explicitly).

... not bother with plugging (no point if no seek penalty) ...

I thought there was considerable advantage to plugging writes (in case they turn out to be adjacent) on current and older generations of non-rotational storage?

For non-queuing devices, I think our current check is a bit too drastic. We probably want to change that to

int dont_plug(q)

{
        return blk_queue_nonrot(q) && blk_queue_tagged(q);
}

On Thu, Jan 15, 2009 at 11:00 AM, James Bottomley
<[email protected]> wrote:
...

Quoted 8 lines

Quoted 3 lines

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.

From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] block: export SSD/non-rotational queue flag through sysfs

For some devices (i.e. CFA ATA) we can't reliably detect whether the device is of rotational or non-rotational type so we need to leave the final decision about this setting to the user-space.

Suggested-by Alan Cox <[email protected]>