Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp291289imu; Thu, 8 Nov 2018 01:52:50 -0800 (PST) X-Google-Smtp-Source: AJdET5e7fBpiiAFZ+Tuopmq5aJrOyQ3fw3VoBCZ9P3hj4Cjzb3mRYtr54ObOXHnKZfcl9VTBQ1u3 X-Received: by 2002:a62:42dc:: with SMTP id h89-v6mr4024904pfd.0.1541670770115; Thu, 08 Nov 2018 01:52:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541670770; cv=none; d=google.com; s=arc-20160816; b=NzIYciknJXQ+T4PizCRHAwR6vMj7A4GdT4mc6D4jh+SUXeYiy2ALCThaewNuapqiLk w3mGGKRdWCGD24nsRZ+J2CoAIUpkT4C59q5JOq3+Q6hdqhEbsEf8PK7FGd+0xA1i9WBM UaQdizQWSEKuvC+j9J38hTikaI00njGsIcLosHqU9Sjxn2pMQnPHi5YLbrusfX8Vt42e NldyMw/C0dAmXcYy7vBryNDmZ4RC6Q0kivpdAf/Pa+ynE4+MwO+6OxjAR6ma+VTZaM8o AyblU0ex1eQ6n2q6Q1YexJY4jxAc3gMt3yaS6qWx2yonwH0basU2MHMt+vVsgNOFv87I Pgow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=+fdqrZGWaYe24d3IZyFZ6tMU0m7UiAizlKQbjnRGHdg=; b=dY+Skiy/7p79R5aQKc+ygaGMRE+DivZLI5xUed4PLi8FKzTbmCzridVUUbOqqSVLSQ qzPOfGpg7ul8m2Uzn87SW2ZMcz8IzSg8Fj0psNOEiQQfruSdRZRIStRyH8jSObg7IkRr 1NgDkzUAGSfFHHyoeEtcE4AZkuUWkCGEof5MpREZQxA0+CaLHgf5F6n19GjnBaqCcIl9 6ZowXDbbYv2eP+QU3hMER6uZQDs/1NhGlZX1H0Vi7vDs3l6vCtLtvhqtbjktvkxSOwPi YRxjxLNBRaKi/8EhKoO8yk39a7o6Wyy6+WkK5aDdcbSnFjS6kZcpT7SfIH3eMs0nWVWw 2Ekg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=P5AvSY7A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4-v6si4419976pll.50.2018.11.08.01.52.35; Thu, 08 Nov 2018 01:52:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=P5AvSY7A; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727032AbeKHT0v (ORCPT + 99 others); Thu, 8 Nov 2018 14:26:51 -0500 Received: from mail-vs1-f68.google.com ([209.85.217.68]:37356 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726517AbeKHT0v (ORCPT ); Thu, 8 Nov 2018 14:26:51 -0500 Received: by mail-vs1-f68.google.com with SMTP id h18so11232548vsj.4 for ; Thu, 08 Nov 2018 01:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+fdqrZGWaYe24d3IZyFZ6tMU0m7UiAizlKQbjnRGHdg=; b=P5AvSY7AYsuxl55FTwAw1OoiNjU4KTmN7SqJc28xuq5+j1GAp+EWLcV6tXiBgKpkMU HBGbPuF3n1w6foomY/39M5raOI+RsxVAwRErGZxLmFEbslmfp7Gtw+c9GSzgXOeABqc8 xA5JAICZk4kIG3jQawPs4oDN6904pyWhuz9raOqFuXMuBMiRCOI61sNqZ5E3fZIRfqv2 fbxhZPKtxvnUwLxqaVFPzGpaiRfEKsVwqyaLhZg0Da4pY9t2bqTGPDLh/b7FqH1bFjPC SSkx2WWfsloYkIDvg7mWE4R/s1BhCGK61mkIzdnuodw5i2h1GKF2uVqqsveV7Fw64k1i 7aSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+fdqrZGWaYe24d3IZyFZ6tMU0m7UiAizlKQbjnRGHdg=; b=ClXKkoOfReRCcQM5Un8i9KRVoDsKARc5BzlUuMazV6w48zVSjIJzVln9RG83dzS+PJ Sb9tf2z6lSWzSfVUJ7ZGt3WWu4fB7WjGOaqVYBX76iSBCwUt6AEC54zKoy7kl10hkmWG brwZW4RAuZP8gCMbRugDJFBahzZPZmjNONii/xUiIG5RYCXYxEHeK0TJpZ3zUk8mf+NN C3037iRhEFAMVLdBj3Sd6/cvdzubMTn0Phi5VxUPcHBE8+6FUwg3XkNa6erJ167nrrmw SuHmb15TAsWCpX9OvRyaWcrfPTG+VGNdbmBLHQReEuLQ/5qXTnSkjpD8LlCWrViLwbIJ qSRw== X-Gm-Message-State: AGRZ1gI6dvvfTkt8hnOfCnWgQceYLLDgyl5CKBUexHY/9gx3dizZLITZ 3EYK8DyIMmyV5pezoAnmHBMwlRvZZbUQSnjsXgYiEA== X-Received: by 2002:a67:f756:: with SMTP id w22mr1624766vso.30.1541670729401; Thu, 08 Nov 2018 01:52:09 -0800 (PST) MIME-Version: 1.0 References: <20181105155815.i654i5ctmfpqhggj@angband.pl> <79d0c96a-a0a2-63ec-db91-42fd349d50c1@gmail.com> In-Reply-To: <79d0c96a-a0a2-63ec-db91-42fd349d50c1@gmail.com> From: Pintu Agarwal Date: Thu, 8 Nov 2018 15:21:58 +0530 Message-ID: Subject: Re: Creating compressed backing_store as swapfile To: ahferroin7@gmail.com Cc: kilobyte@angband.pl, linux-mm@kvack.org, open list , kernelnewbies@kernelnewbies.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 5, 2018 at 9:37 PM Austin S. Hemmelgarn wrote: > > On 11/5/2018 10:58 AM, Adam Borowski wrote: > > On Mon, Nov 05, 2018 at 08:31:46PM +0530, Pintu Agarwal wrote: > >> Hi, > >> > >> I have one requirement: > >> I wanted to have a swapfile (64MB to 256MB) on my system. > >> But I wanted the data to be compressed and stored on the disk in my swapfile. > >> [Similar to zram, but compressed data should be moved to disk, instead of RAM]. > >> > >> Note: I wanted to optimize RAM space, so performance is not important > >> right now for our requirement. > >> > >> So, what are the options available, to perform this in 4.x kernel version. > >> My Kernel: 4.9.x > >> Board: any - (arm64 mostly). > >> > >> As I know, following are the choices: > >> 1) ZRAM: But it compresses and store data in RAM itself > >> 2) frontswap + zswap : Didn't explore much on this, not sure if this > >> is helpful for our case. > >> 3) Manually creating swapfile: but how to compress it ? > >> 4) Any other options ? > > > > Loop device on any filesystem that can compress (such as btrfs)? The > > performance would suck, though -- besides the indirection of loop, btrfs > > compresses in blocks of 128KB while swap wants 4KB writes. Other similar > > option is qemu-nbd -- it can use compressed disk images and expose them to a > > (local) nbd client. > > Swap on any type of a networked storage device (NBD, iSCSI, ATAoE, etc) > served from the local system is _really_ risky. The moment the local > server process for the storage device gets forced out to swap, you deadlock. > > Performance isn't _too_ bad for the BTRFS case though (I've actually > tested this before), just make sure you disable direct I/O mode on the > loop device, otherwise you run the risk of data corruption. Sorry, btrfs is not an option for us. We want something more lighter weight as our requirement is just < 200 MBs.