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
Date: Mon, 5 May 2014 10:44:23 -0400 [thread overview]
Message-ID: <20140505144423.GG22287@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1405051629270.2223@localhost.localdomain>
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
next prev parent reply other threads:[~2014-05-05 14:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 13:04 [PATCH 1/3] mke2fs: print a message when creating a regular file Theodore Ts'o
2014-05-05 13:04 ` [PATCH 2/3] mke2fs: print extra information about existing ext2/3/4 file systems Theodore Ts'o
2014-05-05 13:45 ` Lukáš Czerner
2014-05-05 14:04 ` Theodore Ts'o
2014-05-05 14:17 ` Lukáš Czerner
2014-05-05 14:28 ` Theodore Ts'o
2014-05-05 14:38 ` Lukáš Czerner
2014-05-05 14:44 ` Theodore Ts'o [this message]
2014-05-05 14:51 ` Lukáš Czerner
2014-05-05 14:57 ` Theodore Ts'o
2014-05-05 16:25 ` Andreas Dilger
2014-05-05 17:50 ` Karel Zak
2014-05-05 18:32 ` Theodore Ts'o
2014-05-06 7:44 ` Karel Zak
2014-05-05 16:30 ` Andreas Dilger
2014-05-05 13:04 ` [PATCH 3/3] mke2fs: check for a partition table and warn if present Theodore Ts'o
2014-05-05 13:52 ` Lukáš Czerner
2014-05-05 13:58 ` Theodore Ts'o
2014-05-05 14:11 ` Lukáš Czerner
2014-05-05 14:20 ` Theodore Ts'o
2014-05-06 12:20 ` Karel Zak
2014-05-06 12:52 ` Lukáš Czerner
2014-05-05 13:41 ` [PATCH 1/3] mke2fs: print a message when creating a regular file Lukáš Czerner
2014-05-05 13:52 ` Theodore Ts'o
2014-05-05 14:04 ` Lukáš Czerner
2014-05-05 14:46 ` Eric Sandeen
2014-05-05 14:49 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140505144423.GG22287@thunk.org \
--to=tytso@mit.edu \
--cc=kzak@redhat.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.