From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754299Ab1DSJ4J (ORCPT ); Tue, 19 Apr 2011 05:56:09 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:63383 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753108Ab1DSJ4I convert rfc822-to-8bit (ORCPT ); Tue, 19 Apr 2011 05:56:08 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=vrfy.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=awZUo7Sa7Q2m5v9UpKMDC70rp7OTFDa3FLzQrcb26EMAWhG7GswX5fiVkbo19vAGUN XEhj5iYnL4hVjdtsfxuj9btZJd7JSFvN1514cI5Lg6s7WvNNsKRhDLUOkda0Hmzp3C/c xy98mLqwb4VFjbD+Qo6srPsEKXhA39v8yrUu0= MIME-Version: 1.0 In-Reply-To: <87ipuar6nq.fsf@linux.vnet.ibm.com> References: <20110412190934.GA12082@redhat.com> <20110412192103.GA13278@redhat.com> <87tye1ckhr.fsf@linux.vnet.ibm.com> <87ipuar6nq.fsf@linux.vnet.ibm.com> From: Kay Sievers Date: Tue, 19 Apr 2011 11:55:50 +0200 Message-ID: Subject: Re: Linux 2.6.39-rc3 To: "Aneesh Kumar K.V" Cc: Dave Jones , Linus Torvalds , Linux Kernel Mailing List , Eric Sandeen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 19, 2011 at 10:23, Aneesh Kumar K.V wrote: > On Tue, 19 Apr 2011 00:57:27 +0200, Kay Sievers wrote: >> Just a simple question about this approach in general? A filesystem >> UUID can be changed on disk at any time (tune2fs -U ...). >> >> Your code looks like you copy the bytes to the in-kernel superblock >> structure without noticing any later changes on disk? How is that >> supposed to work? > > Isn't that true even for the fsid returned by statfs ?.  IIUC tune2fs > won't change even the ext4_super_block.s_uuid . What matter is that it's common practice today, to change labels on-disks of mounted filesystems. There should probably be getter/setter (like generic ioctls, or whatever fits) for uuid/label of a mounted filesystem. That call would also update this new superblock info. Guess that's needed before the kernel can export such stuff in mountinfo. So tools at least have a chance to do it right here, and the current on-disk edit can rightfully be deprecated. Exporting possible out-of-sync data, without the chance to update it without a "reboot" really doesn't sound convincing. Kay