public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Bryan Henderson" <hbryan@us.ibm.com>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
Date: Fri, 23 Mar 2001 09:56:47 -0700	[thread overview]
Message-ID: <OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain> (raw)

How it can be used? Well, say it you've mounted JFS on /usr/local
>% mount -t jfsmeta none /mnt -o jfsroot=/usr/local
>% ls /mnt
>stats     control   bootcode whatever_I_bloody_want
>% cat /mnt/stats
>master is on /usr/local
>fragmentation = 5%
>696942 reads, yodda, yodda
>% echo "defrag 69 whatever 42 13" > /mnt/control
>% umount /mnt

There's a lot of cool simplicity in this, both in implementation and 
application, but it leaves something to be desired in functionality.  This 
is partly because the price you pay for being able to use existing, 
well-worn Unix interfaces is the ancient limitations of those interfaces 
-- like the inability to return adequate error information.

Specifically, transactional stuff looks really hard in this method.
If I want the user to know why his "defrag" command failed, how would I 
pass that information back to him?  What if I want to warn him of of a 
filesystem inconsistency I found along the way?  Or inform him of how 
effective the defrag was?  And bear in mind that multiple processes may be 
issuing commands to /mnt/control simultaneously.

With ioctl, I can easily match a response of any kind to a request.  I can 
even return an English text message if I want to be friendly.


             reply	other threads:[~2001-03-23 16:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-23 16:56 Bryan Henderson [this message]
2001-03-23 17:16 ` [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt) Matthew Wilcox
2001-03-23 18:28   ` Alexander Viro
2001-03-23 17:35 ` Pjotr Kourzanoff
2001-04-01  9:01 ` Chip Salzenberg
2001-04-01 11:48   ` [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentatio Kai Henningsen
2001-04-01 12:50   ` [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt) Keith Owens
2001-04-02 19:49   ` Chip Salzenberg
2001-04-10  7:51     ` Tommi Virtanen
  -- strict thread matches above, loose matches on Subject: below --
2001-03-22 22:06 [PATCH] Documentation/ioctl-number.txt Dave Kleikamp
2001-03-22 23:07 ` [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt) Alexander Viro
2001-03-23  6:00   ` Andreas Dilger
2001-03-23 12:06     ` Alexander Viro
2001-03-23 14:45   ` Eric W. Biederman
2001-03-23 16:15   ` [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt) Dave Kleikamp

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=OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain \
    --to=hbryan@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox