Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Bryan Henderson]

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.

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Matthew Wilcox]

On Fri, Mar 23, 2001 at 09:56:47AM -0700, Bryan Henderson wrote:
> 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.

hmm... open("defrag-error") first, then read from it if it fails?

> effective the defrag was?  And bear in mind that multiple processes may be 
> issuing commands to /mnt/control simultaneously.

you should probably serialise them.  you probably have to do this anyway.

> 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.

yes, one of the nice plan9 changes was the change to returning strings
instead of numerics.

-- 
Revolutions do not require corporate support.

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Alexander Viro]

On Fri, 23 Mar 2001, Matthew Wilcox wrote:

> On Fri, Mar 23, 2001 at 09:56:47AM -0700, Bryan Henderson wrote:
> > 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.
> 
> hmm... open("defrag-error") first, then read from it if it fails?

Or just do
(echo $cmd; read reply) <file >&0
and make write() queue a reply. Yup, on the struct file used for write().

You _will_ need serialization for operations themselves, but for getting
replies... Not really.

> > 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.

So you can with read(). You know, the function that is intended to be used for
reading stuff into user-supplied buffer...

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Pjotr Kourzanoff]

On Fri, 23 Mar 2001, Bryan Henderson wrote:

> 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.

  I can imagine a solution to this using the _same_ method - extend
  /proc/*/ with a new entry (say, trace) for dumping errors. Put data
  in there from every failing function in your code. Normally, this
  will not introduce overheads (not unless you use error conditions to
  pass on useful information), however, in case of errors, you can
  get the backtrace (together with any info you want to put in there)
  immediately.

> 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.

  That's all up to you. Informational messages can go to /proc.
  Transactions/serialization can be done in your filesystem's
  implementation. Maybe glibc guys would even want to extend
  strerror() to handle these cases?

>
> 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.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
>

  Cheers,

Pjotr Kourzanov

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Chip Salzenberg]

In article <OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain> you write:
>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.

But ioctl requires allocation of numbers.  Ugly and hard to scale.

Alex Viro's idea is cleaner, but still requires a fair amount of
coding even for simple interfaces.

Why not have a kernel thread and use standard RPC techniques like
sockets?  Then you'd not have to invent anything unimportant like
Yet Another IPC Technique.
-- 
Chip Salzenberg              - a.k.a. -             <chip@valinux.com>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Keith Owens]

On Sun, 01 Apr 2001 01:01:59 -0800, 
chip@valinux.com (Chip Salzenberg) wrote:
>In article <OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain> you write:
>Why not have a kernel thread and use standard RPC techniques like
>sockets?  Then you'd not have to invent anything unimportant like
>Yet Another IPC Technique.

kerneld (kmod's late unlamented predecessor) used to use Unix sockets
to communicate from the kernel to the daemon.  It forced everybody to
link Unix sockets into the kernel but there are some people out there
who want to use it as a module.  Also the kernel code for communicating
with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Chip Salzenberg]

According to kaos@ocs.com.au:
>chip@valinux.com (Chip Salzenberg) wrote:
>>Why not have a kernel thread and use standard RPC techniques like
>>sockets?  Then you'd not have to invent anything unimportant like
>>Yet Another IPC Technique.
>
>kerneld (kmod's late unlamented predecessor) used to use Unix sockets
>to communicate from the kernel to the daemon.  It forced everybody to
>link Unix sockets into the kernel but there are some people out there
>who want to use it as a module.  Also the kernel code for communicating
>with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.

I see.

On the other hand, file-style (e.g. /proc-style) access works in Plan9
at least inpart because each client makes his own connection to the
server.  Thus, the question of how clients know which response is for
them is trivially solved.  ('Server' would in this case be the JFS
kernel thread.)

Sockets are apparently not the right way to go about getting
transaction support for kernel threads.

AFAIK, Alex Viro's idea of bindable namespaces provides effective
transaction support *ONLY* if there are per-process bindings.  With
per-process bindings, each client that opens a connection does so
through a distinct binding; when that client's responses go back
through the same binding, only that client can see them.

I hope that Alex's namespaces patch, implementing per-process
bindings, goes into the official kernel Real Soon Now.
-- 
Chip Salzenberg              - a.k.a. -             <chip@valinux.com>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Tommi Virtanen]

chip@valinux.com (Chip Salzenberg) writes:

> AFAIK, Alex Viro's idea of bindable namespaces provides effective
> transaction support *ONLY* if there are per-process bindings.  With
> per-process bindings, each client that opens a connection does so
> through a distinct binding; when that client's responses go back
> through the same binding, only that client can see them.

	Not really. We can both open /proc/partitions, read one char at a
        time, and the kernel won't confuse our read positions. Different
        file opens create different instances of state. See struct file,
        void *private_data for how to store arbitrary data.

-- 
tv@{{hq.yok.utu,havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
unix, linux, debian, networks, security, | First snow, then silence.
kernel, TCP/IP, C, perl, free software,  | This thousand dollar screen dies
mail, www, sw devel, unix admin, hacks.  | so beautifully.

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentatio

[Kai Henningsen]

chip@valinux.com (Chip Salzenberg)  wrote on 01.04.01 in <E14jdkF-0007Ps-00@tytlal>:

> Why not have a kernel thread and use standard RPC techniques like
> sockets?  Then you'd not have to invent anything unimportant like
> Yet Another IPC Technique.

You can, of course, transfer the exact same RPC messages over a file  
descriptor on your metadata fs. It doesn't *have* to be ASCII, especially  
not for purely internal-use interfaces.

And for ioctl() fans, you could transfer the exact same data via read()/ 
write() again. That's not significantly harder. Especially if you write a  
wrapper around the calls. If you want to be perverse, you can probably  
even transmit user space pointers.

But I suspect there are really only two generally useful interfaces:

1. A text based interface for generally-useful stuff you might want to  
manipulate from the shell, or random user programs. (From the shell _is_  
random user programs.)

2. A RPC based interface for tightly-coupled fs utilities. (I don't know  
off the top of my head what the kernel already has - ISTR networking has  
_something_.)

Don't forget a version marker of some kind. Sooner or later, you'll be  
glad you have it.

MfG Kai