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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68344C6FD1F for ; Wed, 22 Mar 2023 18:42:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230154AbjCVSme (ORCPT ); Wed, 22 Mar 2023 14:42:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229750AbjCVSm2 (ORCPT ); Wed, 22 Mar 2023 14:42:28 -0400 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97BC464858 for ; Wed, 22 Mar 2023 11:42:17 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id x3so76779899edb.10 for ; Wed, 22 Mar 2023 11:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitmlabs-org.20210112.gappssmtp.com; s=20210112; t=1679510536; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=GTe3n7OwhSgzqoIQ2iOIM4yrg4KI4oJcuqkh7kjwuXY=; b=Q7bonuSCkCN8hOjv0FPyTNs60RcvkqrFId4E5FbWUJ0wtMACXvUUMVeMKIwoLkWLqA LrWPyh5OkOVQgRebCaUkZBcqYNnNc4+iemm6IC5Vd+fGprLqdQjxxFfqpBRFh8VvcJA7 FkK83VXh164YCND2Y12dTFBaZTKKXj+muuDOFLLsd7R37/RAg7j0vNkkh5TRsZ+z/BgN kkwvPi3/yciyC67pQ7+X4FBbZIWtgZ7C98gvv8gk3Wjl5/8jskVofYI+wp4UQl+8jw1F GonTueDZcE4QHTwDOrqj8e1uLY/YlsJAvBnb6e2n9ks3fMiV90c+9vI4c9t6kdj/LWBt 130A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679510536; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GTe3n7OwhSgzqoIQ2iOIM4yrg4KI4oJcuqkh7kjwuXY=; b=sR9o6IO/Qlpb+eZrmfW6sjwL6Gh0BPUrtJDpvhHy95EieLmRxKTz9v9uPJZeBYO+cV hC38IW0/0BL9oQzb7HCtMrNeKGkAJjdXdXcwARSOHL1/NrBY1T/1G6SnIspkA8BwbzJA 0DrLZAPgOiNQbduzP+o1Cq0KpFCMFDSzOuUybES9AdLIN27lE4jC4HOMr+GcmkxhiOfS gOv0Fzr/DudroJ5+VCGahKGO5llDuS1G3id9XI5iqdHG4XysPqxVVHi2QD3vTTygCXgG +f4Ov/8tMLwEKZtqhhjOPgnPpMfiq2VLjaGPPDPjJKrPRGYeI99lsyqkRyYzsDohrOXD sqCQ== X-Gm-Message-State: AO0yUKUrIoWlpOGiHcmPjjYoUtUxAQh+9n1kWZKfJQ4ebHyb55EqjRJC w79iJaRumyVJVPjU4anYpdj/fmQiW95RMjDukF6Ksg== X-Google-Smtp-Source: AK7set9OwQl4tQH3N94ZDG+acssBbhWTsr4FduMnFN8SVEnueMIs6/QUQRrMzUL6yWi0UBkT8ZC3ISY80DHvT16gEio= X-Received: by 2002:a50:9ecb:0:b0:501:d489:f797 with SMTP id a69-20020a509ecb000000b00501d489f797mr4142134edf.1.1679510535961; Wed, 22 Mar 2023 11:42:15 -0700 (PDT) MIME-Version: 1.0 References: <4B9D76D5-C794-4A49-A76F-3D4C10385EE0@kohlschutter.com> <83A29F9C-1A91-4753-953A-0C98E8A9832C@kohlschutter.com> <56E6CAAE-FF25-4898-8F9D-048164582E7B@kohlschutter.com> <490c5026-27bd-1126-65dd-2ec975aae94c@eitmlabs.org> In-Reply-To: Reply-To: jonathan@eitm.org From: Jonathan Katz Date: Wed, 22 Mar 2023 11:42:00 -0700 Message-ID: Subject: Re: [PATCH] [REGRESSION] ovl: Handle ENOSYS when fileattr support is missing in lower/upper fs To: Miklos Szeredi Cc: jonathan@eitm.org, =?UTF-8?Q?Christian_Kohlsch=C3=BCtter?= , Linus Torvalds , overlayfs , linux-kernel , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-unionfs@vger.kernel.org Confirmed bindfs interaction: Based on your bindfs comment I redid my configuration as follows: ORIGINAL (FAILS): FS1 - exports "/Data" (nfs) FS2 - Mounts "/Data", does a bindfs, does an overlay TEST (SUCCEEDS): FS1 - does a bindfs and exports a series of directories: # bindfs -u 5007, -g 5007 /Data /Data-jiajun /etc/exports: /Data machine.org(ro,sync,no_subtree_check) /Data-jiajun machine.org(ro,fsid=3D12,sync,no_subtree_c= heck) FS2 - used to do bindfs to make the lowers, but, now mounts "/Data-jiajun" as the lower FS2 then does the overlay and samba share. It would not let me do the 2nd export if I did not include the fsid entry.... WOOT WOOT. Not an ideal solution as I have to make changes to 2 servers in order to accomplish my goal :/. On Tue, Mar 14, 2023 at 7:43=E2=80=AFPM Jonathan Katz = wrote: > > On Thu, Mar 9, 2023 at 7:31=E2=80=AFAM Miklos Szeredi = wrote: > > > > On Tue, 7 Mar 2023 at 18:14, Jonathan Katz wrote: > > > > > > On Tue, Mar 7, 2023 at 12:38=E2=80=AFAM Miklos Szeredi wrote: > > > > > > > > On Tue, 7 Mar 2023 at 02:12, Jonathan Katz wro= te: > > > > > > > > > > Hi all, > > > > > > > > > > In pursuing this issue, I downloaded the kernel source to see if = I > > > > > could debug it further. In so doing, it looks like Christian's p= atch > > > > > was never committed to the main source tree (sorry if my terminol= ogy > > > > > is wrong). This is up to and including the 6.3-rc1. I could als= o > > > > > find no mention of the fix in the log. > > > > > > > > > > I am trying to manually apply this patch now, but, I am wondering= if > > > > > there was some reason that it was not applied (e.g. it introduces= some > > > > > instability?)? > > > > > > > > It's fixing the bug in the wrong place, i.e. it's checking for an > > > > -ENOSYS return from vfs_fileattr_get(), but that return value is no= t > > > > valid at that point. > > > > > > > > The right way to fix this bug is to prevent -ENOSYS from being > > > > returned in the first place. > > > > > > > > Commit 02c0cab8e734 ("fuse: ioctl: translate ENOSYS") fixes one of > > > > those bugs, but of course it's possible that I missed something in > > > > that fix. > > > > > > > > Can you please first verify that an upstream kernel (>v6.0) can als= o > > > > reproduce this issue? > > > > > > Got ya. that makes a lot of sense, thank you. > > > > > > I have confirmed that I continue to get the error with 6.2 . > > > quick summary of the lowerdir: > > > server ---- NFS(ro) ---- > client "/nfs" > > > client "/nfs" --- bindfs(uidmap) --- > client "/lower" > > > > Can you please run bindfs in debugging mode (-d) and send the > > resulting log after reproducing the issue? > > > > Thanks, > > Miklos > > OUCH -- MY LAST EMAIL WAS REJECTED FOR BEING TOO BIG > I HOPE THAT I AM SUMMARIZING THE RELEVANT INFORMATION HERE: > > > Hi Miklos, thank you.... I am sorry for the delay. > > The log is somewhat long and was sent in a separate email. > > I broke up the log into entries to try to match the chronology of actions= : > * ENTRY 1 nfs mount the external drive > * ENTRY 2 perform the bind fs > * ENTRY 3 perform the overlay > * ENTRY 4 restart smb > * ENTRY 5 mount the filesystem on a windows box > * ENTRY 6 performing some navigation on the windows file explorer > * ENTRY 7 attempt to open a data file with the windows application. > > The only place that generated a kernel error in dmesg was at ENTRY 7. > > Because the logs are so big, I tried to parse them, I may have made a > mistake or omitted information -- if you think so, as mentioned, the > full bindfs logs were sent separately > > > Here is my attempt to parse out the errors associated with this dmesg ent= ry: > > [ 1925.705908] overlayfs: failed to retrieve lower fileattr (8020 > MeOHH2O RecoverySample1-20221216-A-JJL-WebinarHilic10C-TOF-TT54-Neg-1632.= d/chromatography-data.sqlite, > err=3D-38) > > -- > unique: 1550, opcode: GETXATTR (22), nodeid: 71, insize: 73, pid: 3458 > getxattr /eimstims1/deleteme2/8020 MeOHH2O > RecoverySample1-20221216-A-JJL-WebinarHilic10C-TOF-TT54-Neg-1632.d/chroma= tography-data-pre.sqlite > trusted.overlay.metacopy 0 > unique: 1550, error: -95 (Operation not supported), outsize: 16 > -- > unique: 3922, opcode: GETXATTR (22), nodeid: 71, insize: 72, pid: 3458 > getxattr /eimstims1/deleteme2/8020 MeOHH2O > RecoverySample1-20221216-A-JJL-WebinarHilic10C-TOF-TT54-Neg-1632.d/chroma= tography-data-pre.sqlite > system.posix_acl_access 132 > unique: 3922, error: -95 (Operation not supported), outsize: 16 > -- > unique: 3954, opcode: GETXATTR (22), nodeid: 71, insize: 72, pid: 3458 > getxattr /eimstims1/deleteme2/8020 MeOHH2O > RecoverySample1-20221216-A-JJL-WebinarHilic10C-TOF-TT54-Neg-1632.d/chroma= tography-data-pre.sqlite > system.posix_acl_access 132 > unique: 3954, error: -95 (Operation not supported), outsize: 16 > -- > unique: 3960, opcode: GETXATTR (22), nodeid: 71, insize: 72, pid: 3458 > getxattr /eimstims1/deleteme2/8020 MeOHH2O > RecoverySample1-20221216-A-JJL-WebinarHilic10C-TOF-TT54-Neg-1632.d/chroma= tography-data-pre.sqlite > system.posix_acl_access 132 > unique: 3960, error: -95 (Operation not supported), outsize: 16 > > > Thank you again! > > -Jonathan