From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F187C10DCE for ; Wed, 18 Mar 2020 13:36:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40C9B20774 for ; Wed, 18 Mar 2020 13:36:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Jww7hBgQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726777AbgCRNg5 (ORCPT ); Wed, 18 Mar 2020 09:36:57 -0400 Received: from mail-il1-f177.google.com ([209.85.166.177]:35565 "EHLO mail-il1-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726774AbgCRNg5 (ORCPT ); Wed, 18 Mar 2020 09:36:57 -0400 Received: by mail-il1-f177.google.com with SMTP id v6so12454945ilq.2; Wed, 18 Mar 2020 06:36:56 -0700 (PDT) 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=QOa1wjQr90ahh8o3G0Q0d26hwJPvvcel6LlNVGh6TME=; b=Jww7hBgQbvYQdK3vSQORjjpmOQ4mf8FX6Y1Gucj+mc36olb3q5cGyrWrC79lHFWbG4 Qhsl0jFhdcoNjE7GyR5R9fJZtsytDDQW5PDVPQWSp4k/Dmvcnv3HYEffjw+rrdEemUnt pt45SyPfi8aAnn9lJjxUWFNXHDsC6dWpLu+5dDDsbaNu9p7fBTglZujuuVpSihDT8ncp /5T7tADvIzqVhG9tfHxocta8JTvKp9tNrCWR+BuTXE6DI4jW3LqQQos4wNKHnLHDQMOk 9uiAo6LOOyMctKoyX+iqCLggzBFbaDQgUzRTblzDHXFHfBRWbPRfhavGZS0z7eIAqseK MkJQ== 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=QOa1wjQr90ahh8o3G0Q0d26hwJPvvcel6LlNVGh6TME=; b=KZUZHE3SkCutA3lvxyxbe5KkpvLpJeQdhnxB6Z0PG2vJqhGYr3yIDd4AysLVRYe3Fd Cb6SrGzHtaH4FkWI8E+Gs8/pSRNrrxDJVUhZcJGqz04m3fX85jnjzCk8s4DMEGMG6Beu xN1pYxjdhNONWpfh0EY23yjZmn7rA0zS86IT5Nka2bl9bcPn8pD0mrNqCIrWTC+t8cM7 E7Wyjblkn5lQeL/hwj4PT+n6XaHL3RTCTPTvWljtH1GiK2EQyYLk5ADIa0e9LhCsJlNe TyERkm2W8St5+CnlXZKiaWxi1mPpPqCtcUh0pd9IRa3YgonvgSWPyZjHQ1F9mPSAZJxH MdRg== X-Gm-Message-State: ANhLgQ2/Jy7iU54avfET+NsgeqPr4M3DyzuvV8joWSnbq/DRRylNao+x WtcoprnMjO9MNnGcPjY6Zgr8t0tTYmXImwB0Ex8= X-Google-Smtp-Source: ADFU+vuSm/R9YPj8QRZNx1Vx4lqoj5FR3PJp2aZFIxvLESq6TfsNiHARXSiUvP29xgOIjdBwfwMB5bRWCbD133ZsBq0= X-Received: by 2002:a92:5b51:: with SMTP id p78mr3955852ilb.250.1584538616142; Wed, 18 Mar 2020 06:36:56 -0700 (PDT) MIME-Version: 1.0 References: <20200131115004.17410-1-mszeredi@redhat.com> <20200131115004.17410-5-mszeredi@redhat.com> <20200204145951.GC11631@redhat.com> <20200316175453.GB4013@redhat.com> In-Reply-To: From: Amir Goldstein Date: Wed, 18 Mar 2020 15:36:44 +0200 Message-ID: Subject: Re: unionmount testsuite with upper virtiofs To: Vivek Goyal Cc: Miklos Szeredi , Miklos Szeredi , overlayfs , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-unionfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-unionfs@vger.kernel.org > > I also wanted to run either overlay xfstests or unionmount-testsuite. But > > none of these seem to give me enough flexibility where I can specify > > that overlayfs needs to be mounted on top of virtiofs. > > > > I feel that atleast for unionmount-testsuite, there should be an > > option where we can simply give a target directory and tests run > > on that directory and user mounts that directory as needed. > > > > Need to see how patches look. > Don't want too much configuration complexity, but I agree that some > flexibly is needed. > Maybe the provided target directory should be the upper/work basedir? > Vivek, I was going to see what's the best way to add the needed flexibility, but then I realized I had already implemented this undocumented feature. I have been using this to test overlay over XFS as documented here: https://github.com/amir73il/overlayfs/wiki/Overlayfs-testing#Setup_overlayfs_mount_over_XFS_with_reflink_support That's an example of how to configure a custom /base mount for --samefs to be xfs. Similar hidden feature exists for configuring a custom /lower and /upper mounts via fstab, but I don't think I ever tested those, so not sure if they work as expected. unionmount testsuite will first try to mount the entry from fstab and fallback to mounting tmpfs. I admit this a lousy configuration method, but we could make it official using env vars or something. I also never liked the fact that unionmount testsuite hard codes the /lower /upper /mnt paths. The reason we 'need' the instructions how to mount the fs as opposed to an already mounted dir is that unmounting the underlying fs exposes dentry/inode reference leaks by overlayfs. But it is nice to have and xfstests has support for configuring an already mounted overlayfs for the generic tests. So if you think that you cannot use the existing hack and that pointing to an already mounted /upper or mounted overlay is needed, I suggest that you experiment with patches to make that change. Thanks, Amir.