From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Mestnik Subject: Re: [REPOST][PATCH][RFC] vfs: add message print mechanism for the mount/umount into the VFS layer Date: Thu, 14 Jan 2010 03:03:14 -0600 Message-ID: References: <20100114154837.734fff60.toshi.okajima@jp.fujitsu.com> <20100114081448.GI19799@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE To: linux-fsdevel@vger.kernel.org, Al Viro , tytso@mit.edu, Toshiyuki Okajima Return-path: Received: from mail-ew0-f209.google.com ([209.85.219.209]:45651 "EHLO mail-ew0-f209.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756359Ab0ANJDR convert rfc822-to-8bit (ORCPT ); Thu, 14 Jan 2010 04:03:17 -0500 Received: by ewy1 with SMTP id 1so703154ewy.28 for ; Thu, 14 Jan 2010 01:03:15 -0800 (PST) In-Reply-To: <20100114081448.GI19799@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jan 14, 2010 at 2:14 AM, Al Viro wrot= e: > On Thu, Jan 14, 2010 at 03:48:37PM +0900, Toshiyuki Okajima wrote: >> Hi. >> >> Now, on the VFS-layer any messages aren't printed at mount/umount ti= me >> (when the operation normally terminates). >> But there are some filesystems which print their own specific messag= es at those >> times. >> >> For the purpose of the system management and so on, users (especiall= y, >> enterprise users) want to observe their system operations from the s= ystem logs. >> We may manage to observe some filesystems' operations (mount/umount)= from the >> logs. But the filesystems of which we can observe the operations are= not all. >> >> Therefore to achieve the observations for all filesystems is to add = the common >> message mechanism into the VFS layer. If any filesystems' specific m= essages at >> mount/umount time are added into this, we can distinguish more easil= y each >> message among the system logs for our systems' observations. >> >> This patch provides the following: >> - message output of common format from VFS at mount/umount time >> - the functions of printing the filesystem's specific information at >> =A0 mount/umount time > > I am not going to apply that. =A0For one thing, printk is improper me= chanism > for "observing [normal] operations". =A0Vague references to "enterpri= se > users" wanting that do not constitute a valid rationale. > > What's more, there is absolutely no point in taking care to have moun= t(2) > spew something in log when explicitly asked to do so; caller can bloo= dy > well do it itself. =A0From userland. =A0And on umount side your logic= s is > simply b0rken, since the presence of report depends on the order of v= fsmount > demise in case when there are several vfsmounts over given superblock= =2E > There is something to the kernel's verbose report of a file system mount. For example only the kernel will have access to the feature set that was successfully initiated. Userspace can guess by examining the superblock and the kernels list of supported features, but that's a long shot to start with. > I can see a value in having something e.g. in /proc that would report= the > list of active filesystems (or active filesystems of given type). =A0= poll()able, > a-la /proc/mounts. =A0Format of such thing would have to be considere= d > carefully, but at least it's something that might make sense. This information is useful long after the file system is mounted and the current mounts is a-la /etc/fstab|mtab, no need to fix that ;). If there was a project to implement a poll()able mounts I'd also suggest an extended /proc/mounts that showed the filesystem's available features, highlighting the ones that impact userland(like the missing functionality that exists in fat and ntfs). I know these examples are rather static, but the idea would apply to file systems /w or w/o extent for example as ext4 can have it both ways. The difference from mounts is that these are not user tunable parameters and the goal is to express the kernels usefulness/effectiveness against a given filesystem. One project that could build on this would be an fuse project that creates meta-files(optionally on another filesystem) to plug these holes providing the umsdos functionality. I myself have used split to place large files on vfat, perhaps the future is an fuse application that does this on the users behalf and can be extended to manage sparse files as well. -- 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