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

[EMAIL PROTECTED] (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

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

[EMAIL PROTECTED] (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

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

According to [EMAIL PROTECTED]: >[EMAIL PROTECTED] (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

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

According to [EMAIL PROTECTED]: [EMAIL PROTECTED] (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

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

On Sun, 01 Apr 2001 01:01:59 -0800, [EMAIL PROTECTED] (Chip Salzenberg) wrote: >In article 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

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

In article 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

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

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

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

On Sun, 01 Apr 2001 01:01:59 -0800, [EMAIL PROTECTED] (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

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

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 >

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

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

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

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

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

Al, I didn't know that creating file system ioctl's was such a hot topic. Since the functions I want to implement are for a very specific purpose (I don't expect anything except the JFS utilities to invoke them), I would expect an ioctl to be an appropriate vehicle. If not ioctl's, why not

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

Alexander Viro <[EMAIL PROTECTED]> writes: > IOW, you can get normal filesystem view (meaning that you have all usual > UNIX toolkit available) for per-fs control stuff. And keep the ability to > do proper locking - it's the same driver that handles the main fs and you > have access to

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

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%

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

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

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

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

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

Al, I didn't know that creating file system ioctl's was such a hot topic. Since the functions I want to implement are for a very specific purpose (I don't expect anything except the JFS utilities to invoke them), I would expect an ioctl to be an appropriate vehicle. If not ioctl's, why not

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

Alexander Viro [EMAIL PROTECTED] writes: IOW, you can get normal filesystem view (meaning that you have all usual UNIX toolkit available) for per-fs control stuff. And keep the ability to do proper locking - it's the same driver that handles the main fs and you have access to superblock. No