[cc: linux-block] On 05/12/16 22:28, gwendal grignou wrote: > Holger Hoffstätte <holger.hoffstaette <at> googlemail.com> writes: > >> >> On 11/11/15 23:08, Holger Hoffstätte wrote: >>> On 11/11/15 22:29, Jens Axboe wrote: >>>> On 11/11/2015 08:21 AM, Holger Hoffstätte wrote: >>>>> >>>>> The loop driver always declares the rotational flag of its device as >>>>> rotational, even when the device of the mapped file is nonrotational, >>>>> as is the case with SSDs or on tmpfs. This can confuse filesystem > tools >>>>> which are SSD-aware; in my case I frequently forget to tell > mkfs.btrfs >>>>> that my loop device on tmpfs is nonrotational, and that I really > don't >>>>> need any automatic metadata redundancy. >>>>> >>>>> The attached patch fixes this by introspecting the rotational flag of > the >>>>> mapped file's underlying block device, if it exists. If the mapped > file's >>>>> filesystem has no associated block device - as is the case on e.g. > tmpfs - >>>>> we assume nonrotational storage. If there is a better way to identify > such >>>>> non-devices I'd love to hear them. >>>>> >>>>> Signed-off-by: Holger Hoffstätte <holger.hoffstaette <at> > googlemail.com> > >> >> Jens, >> >> I haven't seen this merged in any trees yet and was wondering if there's >> any chance to get this into 4.5? If there's something left to fix up > please >> let me know. >> >> Thanks, >> Holger >> >> > This patch proved useful for ureadahead: when we use it on a loop device, > it would use the HDD method to place the data in cache using the pack > information instead of the SSD method. > > Signed-off-by: Gwendal Grignou <gwendal@xxxxxxxxxxxx> I had completely forgotten about this, and apparently so had Jens. ;) Thanks for the feedback, glad to hear it is useful. Jens, any objections to merge this for 4.7? It should still apply cleanly. The original patch was at: https://lkml.org/lkml/2015/11/11/288 Thanks, Holger -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
