Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!sun-barr!newstop!exodus!appserv!slovax.Eng.Sun.COM!lm
From: lm@slovax.Eng.Sun.COM (Larry McVoy)
Newsgroups: comp.unix.internals
Subject: Re: Ideas for changes to Unix filesystem
Message-ID: <414@appserv.Eng.Sun.COM>
Date: 4 Feb 91 03:54:50 GMT
References: <1991Jan30.143326.16676@socs.uts.edu.au>
Sender: news@appserv.Eng.Sun.COM
Reply-To: lm@slovax.Eng.Sun.COM (Larry McVoy)
Organization: Sun Microsystems, Mt. View, CA.
Lines: 60

In article <1991Jan30.143326.16676@socs.uts.edu.au> jeremy@socs.uts.edu.au (Jeremy Fitzhardinge) writes:
>1 - a flink(char *path, int fd) system call/operation.

Perfectly reasonable.  Almost everything that takes a pathname as an arg is
already written as

func(char *p, args...)
{
	struct	vnode *vp;

	lookuppn(p, &vp, dirvp...);
	cfunc(vp, args...);
}

ffunc(int fd, args)
{
	struct	file fp;

	fp = GETF(fd);
	cfunc((struct vnode*)fp->f_data, args...);
}

>2 - insertion/deletion in the middle of a file without copying
>
>result of the way the filesystem is designed.  What I was thinking about
>is having the logical size of each block in the indirect blocks, as well
>as their location.  

This is normally known as an extent, i.e, a <bn, length> tuple.

>[much stuff about insertion alg deleted]

I'm not very interested in this idea.  While I agree that it is nice to
be able to say "vi 100MBfile", insert some junk, and write it out, and
have it all happen quickly, I question that this is a common enough
operation that you really want to cram this sort of complexity into the
file system.  If you really need it, build it inot the application using
multiple files.  You can also mitigate the copy stuff (it may be that 
some editors do this already) by rewriting the data from the change on
down.

>3 - limited sized files
>
>This idea is essentially quite similar to the above - basically I've
>been sick of simple log files that grow and grow without bound, often
>making serious holes in a file system.  

There is a per process file size limit.  Find the offending processes and
crank down their limit.  That's what it is there for.  Better yet, write
a crontab entry that goes in, deletes all but the last N lines/bytes/whatever
of data.  This is an administration issue, not a file system issue.

>These are ideas that may be implemented in a filesystem that's currently
>being designed.  I would quite like comments and ideas from fellow
>experienced Unix users/hackers.

You got 'em.  I'd like to know who/where/why this file system is being designed
on when/where/how it will be released.
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com