Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Lukáš Czerner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1700 bytes --]

On Mon, 5 May 2014, Theodore Ts'o wrote:

> Date: Mon, 5 May 2014 10:28:08 -0400
> From: Theodore Ts'o <tytso@mit.edu>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
> Subject: Re: [PATCH 2/3] mke2fs: print extra information about existing
>     ext2/3/4 file systems
> 
> On Mon, May 05, 2014 at 10:04:01AM -0400, Theodore Ts'o wrote:
> > The basic idea behinid these patches is that we now get a bit more
> > context with the warning message for ext2/3/4 file systems:
> > 
> > % ./misc/mke2fs -t ext4 /dev/heap/media
> > mke2fs 1.42.9 (4-Feb-2014)
> > /dev/heap/media contains a ext4 file system labelled 'media'
> > 		  last mounted on /media on Mon May  5 08:59:53 2014
> > Proceed anyway? (y,n) 
> 
> And actually, the place where this context is critically important is
> in this case (where let's say, the user typo's sdc3 when they meant to
> type sdd3):
> 
> % ./misc/mke2fs -t ext4 /dev/sdc3
> mke2fs 1.42.9 (4-Feb-2014)
> /dev/sdc3 contains a ext4 file system
> 	last mounted on /SOX-backups on Mon May  5 08:59:53 2014
> Proceed anyway? (y,n) 
> 
> ... where this becomes a last-ditch saving through against the
> accidental wiping of the enterprise's Sarbanes-Oxley records.  :-)
> 
> 						- Ted

Yep, it's really useful. I just was not sure what is this all about since
there was not description and I was missing context from the other patches.

But this makes me think that it would be very useful if blkid could
gather this information for other file system if possible :). This
might be very useful if we can get some overlap with other file
system with the information provided in superblock.

Karel, what do you think ?

-Lukas

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Theodore Ts'o]

On Mon, May 05, 2014 at 04:38:37PM +0200, Lukáš Czerner wrote:
> > % ./misc/mke2fs -t ext4 /dev/sdc3
> > mke2fs 1.42.9 (4-Feb-2014)
> > /dev/sdc3 contains a ext4 file system
> > 	last mounted on /SOX-backups on Mon May  5 08:59:53 2014
> > Proceed anyway? (y,n) 
> > 
> > ... where this becomes a last-ditch saving through against the
> > accidental wiping of the enterprise's Sarbanes-Oxley records.  :-)
> > 
> 
> Yep, it's really useful. I just was not sure what is this all about since
> there was not description and I was missing context from the other patches.
> 
> But this makes me think that it would be very useful if blkid could
> gather this information for other file system if possible :). This
> might be very useful if we can get some overlap with other file
> system with the information provided in superblock.

Unfortunately, as far as I know, none of the other file systems
currently save the location where the file system was last mounted.
And to be honest, the way we do it in ext4 is a horrible hack (get out
your barf bags!):

static int ext4_file_open(struct inode * inode, struct file * filp)
{
	struct super_block *sb = inode->i_sb;
	struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
	struct vfsmount *mnt = filp->f_path.mnt;
	struct path path;
	char buf[64], *cp;

	if (unlikely(!(sbi->s_mount_flags & EXT4_MF_MNTDIR_SAMPLED) &&
		     !(sb->s_flags & MS_RDONLY))) {
		sbi->s_mount_flags |= EXT4_MF_MNTDIR_SAMPLED;
		/*
		 * Sample where the filesystem has been mounted and
		 * store it in the superblock for sysadmin convenience
		 * when trying to sort through large numbers of block
		 * devices or filesystem images.
		 */
		memset(buf, 0, sizeof(buf));
		path.mnt = mnt;
		path.dentry = mnt->mnt_root;
		cp = d_path(&path, buf, sizeof(buf));
		...

What we would need to do is file a feature request in the other file
systems to save this information, and then add proper support for to
pass this information from the VFS layer into the struct
super_operations's mount function, which would be the proper, sane way
to provide this functionality.

						- Ted




--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Lukáš Czerner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2818 bytes --]

On Mon, 5 May 2014, Theodore Ts'o wrote:

> Date: Mon, 5 May 2014 10:44:23 -0400
> From: Theodore Ts'o <tytso@mit.edu>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>, kzak@redhat.com,
>     linux-fsdevel@vger.kernel.org
> Subject: Re: [PATCH 2/3] mke2fs: print extra information about existing
>     ext2/3/4 file systems
> 
> On Mon, May 05, 2014 at 04:38:37PM +0200, Lukáš Czerner wrote:
> > > % ./misc/mke2fs -t ext4 /dev/sdc3
> > > mke2fs 1.42.9 (4-Feb-2014)
> > > /dev/sdc3 contains a ext4 file system
> > > 	last mounted on /SOX-backups on Mon May  5 08:59:53 2014
> > > Proceed anyway? (y,n) 
> > > 
> > > ... where this becomes a last-ditch saving through against the
> > > accidental wiping of the enterprise's Sarbanes-Oxley records.  :-)
> > > 
> > 
> > Yep, it's really useful. I just was not sure what is this all about since
> > there was not description and I was missing context from the other patches.
> > 
> > But this makes me think that it would be very useful if blkid could
> > gather this information for other file system if possible :). This
> > might be very useful if we can get some overlap with other file
> > system with the information provided in superblock.
> 
> Unfortunately, as far as I know, none of the other file systems
> currently save the location where the file system was last mounted.
> And to be honest, the way we do it in ext4 is a horrible hack (get out
> your barf bags!):
> 
> static int ext4_file_open(struct inode * inode, struct file * filp)
> {
> 	struct super_block *sb = inode->i_sb;
> 	struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
> 	struct vfsmount *mnt = filp->f_path.mnt;
> 	struct path path;
> 	char buf[64], *cp;
> 
> 	if (unlikely(!(sbi->s_mount_flags & EXT4_MF_MNTDIR_SAMPLED) &&
> 		     !(sb->s_flags & MS_RDONLY))) {
> 		sbi->s_mount_flags |= EXT4_MF_MNTDIR_SAMPLED;
> 		/*
> 		 * Sample where the filesystem has been mounted and
> 		 * store it in the superblock for sysadmin convenience
> 		 * when trying to sort through large numbers of block
> 		 * devices or filesystem images.
> 		 */
> 		memset(buf, 0, sizeof(buf));
> 		path.mnt = mnt;
> 		path.dentry = mnt->mnt_root;
> 		cp = d_path(&path, buf, sizeof(buf));
> 		...
> 
> What we would need to do is file a feature request in the other file
> systems to save this information, and then add proper support for to
> pass this information from the VFS layer into the struct
> super_operations's mount function, which would be the proper, sane way
> to provide this functionality.
> 
> 						- Ted

Which would be reasonable if there was a consumer of such
information and it seemed to be useful. So I wonder what other
people think about that.

Karel, you had some suggestions about how to utilize that aside from
the mkfs...

-Lukas

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Theodore Ts'o]

On Mon, May 05, 2014 at 04:51:25PM +0200, Lukáš Czerner wrote:
> 
> Which would be reasonable if there was a consumer of such
> information and it seemed to be useful. So I wonder what other
> people think about that.
> 
> Karel, you had some suggestions about how to utilize that aside from
> the mkfs...

Well, if we were going to make this be more general, one other thought
I had was that might be useful to also stash the last hostname in the
superblock.  Consider the situation where you have several hundred
fibre-channel disk volumes in your SAN, and where of course the SAN
administrator hasn't done a good job naming them, and of course the
human sysadmins hadn't bothered to use file system labels.  If we were
automatically stashing the hostname into the superblock at mount time,
it might help in certain cases after the SAN directory gets smashed,
or some such.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Andreas Dilger]

Note that the MMP block already contains the hostname for informational purposes. 

I'd argue that if you have several hundred SAN attached disks and they are not zoned for specific nodes then using MMP will save your bacon from foolish admins that are trying to use the same disk on multiple nodes. 

Cheers, Andreas

> On May 5, 2014, at 8:57, Theodore Ts'o <tytso@mit.edu> wrote:
> 
>> On Mon, May 05, 2014 at 04:51:25PM +0200, Lukáš Czerner wrote:
>> 
>> Which would be reasonable if there was a consumer of such
>> information and it seemed to be useful. So I wonder what other
>> people think about that.
>> 
>> Karel, you had some suggestions about how to utilize that aside from
>> the mkfs...
> 
> Well, if we were going to make this be more general, one other thought
> I had was that might be useful to also stash the last hostname in the
> superblock.  Consider the situation where you have several hundred
> fibre-channel disk volumes in your SAN, and where of course the SAN
> administrator hasn't done a good job naming them, and of course the
> human sysadmins hadn't bothered to use file system labels.  If we were
> automatically stashing the hostname into the superblock at mount time,
> it might help in certain cases after the SAN directory gets smashed,
> or some such.
> 
>                        - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Karel Zak]

On Mon, May 05, 2014 at 04:51:25PM +0200, Lukáš Czerner wrote:
> On Mon, 5 May 2014, Theodore Ts'o wrote:
> > What we would need to do is file a feature request in the other file
> > systems to save this information, and then add proper support for to
> > pass this information from the VFS layer into the struct
> > super_operations's mount function, which would be the proper, sane way
> > to provide this functionality.
> > 
> > 						- Ted
> 
> Which would be reasonable if there was a consumer of such
> information and it seemed to be useful. So I wonder what other
> people think about that.
> 
> Karel, you had some suggestions about how to utilize that aside from
> the mkfs...

 It's really simple to add another NAME=value to the low-level part of
 the libblkid (used to feed udev db). The question is how usable will
 that, I can imagine:

   1) audit / logging purpose
   2) mount <device> --last-target
   3) automount (for example udisks and removable media)

 unfortunately 2) and 3) seem fragile as the filesystem superblocks
 have no clue about namespaces and the same filesystem is possible to
 mount in the same time to more places, etc.
 
 BTW, the current trend is to use GPT partition types to identify
 purpose of the partition filesystem (for example extra GUID for
 /home). It's FS independent solution and it allows use the right
 filesystems for the right mountpoints. It's very attractive for
 example for virtual images where you don't have to setup fstab and
 identify FS, but you still have (for example) /home on the right
 place.

     Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Theodore Ts'o]

On Mon, May 05, 2014 at 07:50:49PM +0200, Karel Zak wrote:
>    1) audit / logging purpose
>    2) mount <device> --last-target
>    3) automount (for example udisks and removable media)
> 
>  unfortunately 2) and 3) seem fragile as the filesystem superblocks
>  have no clue about namespaces and the same filesystem is possible to
>  mount in the same time to more places, etc.

Yes, "location last mounted" is really only useful as a backup
mechanism.  I've never claimed that it would be guaranteed to be the
most useful thing in the presence of bind mounts, namespaces, being
mounted in multiple locations, etc.  *Usually,* the namespace the first
time the file system is mounted is more interesting than subsequent
mounts or bind mounts, but there really is no guarantee.

>  BTW, the current trend is to use GPT partition types to identify
>  purpose of the partition filesystem (for example extra GUID for
>  /home). It's FS independent solution and it allows use the right
>  filesystems for the right mountpoints. It's very attractive for
>  example for virtual images where you don't have to setup fstab and
>  identify FS, but you still have (for example) /home on the right
>  place.

But a partition only gets one GUUID and one partition type.  So are
you saying that the GUUID partition type would be used to indicate the
concept of "this is the file system for /home", *instead* of "this is
an btrfs file system" or "this is an ext4 file system"?

Or is this some kind of GPT extension that I'm not aware of?

      	   	     	    	      	   - Ted

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Karel Zak]

On Mon, May 05, 2014 at 02:32:53PM -0400, Theodore Ts'o wrote:
> >  BTW, the current trend is to use GPT partition types to identify
> >  purpose of the partition filesystem (for example extra GUID for
> >  /home). It's FS independent solution and it allows use the right
> >  filesystems for the right mountpoints. It's very attractive for
> >  example for virtual images where you don't have to setup fstab and
> >  identify FS, but you still have (for example) /home on the right
> >  place.
> 
> But a partition only gets one GUUID and one partition type.  So are
> you saying that the GUUID partition type would be used to indicate the
> concept of "this is the file system for /home", *instead* of "this is
> an btrfs file system" or "this is an ext4 file system"?

 Yes, GPT partition has two UUIDs, 
 
   - UUID = an unique partition identifier
   - GUID = partition type identifier

 I talked about the type (GUID). Note that this concept is just
 another point of view how to mount partitions, I don't think it will
 be a mainstream solution for standard machines. Now it's supported by
 systemd. More details:

  http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
 

 For old good fstab you can use PARTUUID= to identify partitions and
 to bypass filesystem specific identifiers. In this case it's unique 
 partition identifier, no partition type.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems

[Andreas Dilger]

The last time I asked to have the VFS add mountpoint info to the superblock, it got a strong NACK from Al Viro because of the possibility of multiple mountpoints due to bind mounts or namespaces.

I think the current hack is as good as it gets. 

Cheers, Andreas

> On May 5, 2014, at 8:44, Theodore Ts'o <tytso@mit.edu> wrote:
> 
> On Mon, May 05, 2014 at 04:38:37PM +0200, Lukáš Czerner wrote:
>>> % ./misc/mke2fs -t ext4 /dev/sdc3
>>> mke2fs 1.42.9 (4-Feb-2014)
>>> /dev/sdc3 contains a ext4 file system
>>>    last mounted on /SOX-backups on Mon May  5 08:59:53 2014
>>> Proceed anyway? (y,n) 
>>> 
>>> ... where this becomes a last-ditch saving through against the
>>> accidental wiping of the enterprise's Sarbanes-Oxley records.  :-)
>>> 
>> 
>> Yep, it's really useful. I just was not sure what is this all about since
>> there was not description and I was missing context from the other patches.
>> 
>> But this makes me think that it would be very useful if blkid could
>> gather this information for other file system if possible :). This
>> might be very useful if we can get some overlap with other file
>> system with the information provided in superblock.
> 
> Unfortunately, as far as I know, none of the other file systems
> currently save the location where the file system was last mounted.
> And to be honest, the way we do it in ext4 is a horrible hack (get out
> your barf bags!):
> 
> static int ext4_file_open(struct inode * inode, struct file * filp)
> {
>    struct super_block *sb = inode->i_sb;
>    struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
>    struct vfsmount *mnt = filp->f_path.mnt;
>    struct path path;
>    char buf[64], *cp;
> 
>    if (unlikely(!(sbi->s_mount_flags & EXT4_MF_MNTDIR_SAMPLED) &&
>             !(sb->s_flags & MS_RDONLY))) {
>        sbi->s_mount_flags |= EXT4_MF_MNTDIR_SAMPLED;
>        /*
>         * Sample where the filesystem has been mounted and
>         * store it in the superblock for sysadmin convenience
>         * when trying to sort through large numbers of block
>         * devices or filesystem images.
>         */
>        memset(buf, 0, sizeof(buf));
>        path.mnt = mnt;
>        path.dentry = mnt->mnt_root;
>        cp = d_path(&path, buf, sizeof(buf));
>        ...
> 
> What we would need to do is file a feature request in the other file
> systems to save this information, and then add proper support for to
> pass this information from the VFS layer into the struct
> super_operations's mount function, which would be the proper, sane way
> to provide this functionality.
> 
>                        - Ted
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html