Re: [RFC]swap: don't do discard if no discard option added

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20 Mar 2012, Hugh Dickins wrote:

On Tue, 20 Mar 2012, Shaohua Li wrote:

Even don't add discard option, swapon will do discard, this sounds buggy,
especially when discard is slow or buggy.

It's not a bug in swapon, it's an intentional feature, made explicit in
commit 339944663273 "swap: discard while swapping only if SWAP_FLAG_DISCARD"
and in the swapon(2) manpage.  We were also careful in wording the swapon(8)
manpage and the comment on SWAP_FLAG_DISCARD in swap.h - too lawyerly ;-?

It appears to be a bug in the Vertex 2: I did receive one other such
report on a Vertex 2 fourteen months ago, and in the absence of further
reports, we decided to consider that user's drive defective.  I wonder
if Holger's drive is defective, or if it's true of all Vertex 2s, or
if it depends on the firmware revision, and a later revision fixes it.

I have three of those drives put together via MD to a raid 0 and I do
not think they are defective, since they worked (without discard) so far.
Firmware is also the new-es it's 1.35, just checked with OCZ website.

Thank you for the pointer with the firmware, I have posted a support
question at OCZ.

If the latter (if there is a firmware revision which fixes it), then
I think it's clear that SWAP_FLAG_DISCARD should continue to behave
as it does at present, with discard at swapon independent of it.

Holger, do you have the latest firmware on this drive?

Yes, it has the latest firmware.

Have any other Vertex 2 users observed this behaviour?

I've seen no such problem with the original OCZ Vertex, nor with
their Vertex 3, nor with the Intel drives I've tried (and you
report no problem with FusionIO's, though no advantage either).

But if there's no good firmware for the Vertex 2, I'm not so sure
what to do: two reports in fourteen months, on a superseded drive -
is that strong enough to disable a feature which appeared to offer
some advantage on others?

No, I agree that one should not disable a feature that is useful to so
many, for the reasons you mention. However, it would be good if there
is some way to disable this, other then having to always patch the kernel.

Regards,
Holger

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]