Received-SPF: pass (google.com: domain of linux-kernel+bounces-56831-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 7 Feb 2024 12:40:09 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: brauner@kernel.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/7] filesystem visibililty ioctls
Message-ID: <20240207174009.GF119530@mit.edu>
References: <20240206201858.952303-1-kent.overstreet@linux.dev>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240206201858.952303-1-kent.overstreet@linux.dev>

On Tue, Feb 06, 2024 at 03:18:48PM -0500, Kent Overstreet wrote:
> previous:
> https://lore.kernel.org/linux-fsdevel/20240206-aufwuchs-atomkraftgegner-dc53ce1e435f@brauner/T/
> 
> Changes since v1:
>  - super_set_uuid() helper, per Dave
> 
>  - nix FS_IOC_SETUUID - Al raised this and I'm in 100% agreement,
>    changing a UUID on an existing filesystem is a rare operation that
>    should only be done when the filesystem is offline; we'd need to
>    audit/fix a bunch of stuff if we wanted to support this

NAK.  First, this happens every single time a VM in the cloud starts
up, so it happens ZILLIONS of time a day.  Secondly, there is already
userspace programs --- to wit, tune2fs --- that uses this ioctl, so
nixing FS_IOC_SETUUID will break userspace programs.

							- Ted