On Tue, 2005-11-29 at 12:41, Frank Hofmann - Solaris Sustaining wrote:
> > On Tue, 2005-11-29 at 11:34, [EMAIL PROTECTED] wrote:
> > > >I don't see why the egg-laying, milk-giving woolly UNIX syscall pig
> > > >that is ioctl() couldn't be genetically engineered to concatenate
> > > >files as well ...
> > >
> > > No, not ioctl(), fcntl()! You guys just don't understand the clear
> distinction
> > > between the two interfaces :-)
>
> Yes yes yes, you're right of course. Me getting carried away
> because ufs does too many things in ioctl() ... :)
>
> There's actually one point for using ioctl() vs. fcntl():
> With ioctl(), you don't need to have the file open. You could
> open the fs rootdir, and ioctl(). Completely under the hood.
>
> >
> > hmnn.
> >
> > fcntl(fd1, F_CAT, fd2);
>
> Problem: Does this close fd2 ? If not, what's fd2 after the op ?
I assumed it didn't close fd2 but the seek pointer was at the
end. It also assumed that an fd2 = open(path) had been done already.
> >
> > Looks good to me and just for good measure lets have:
> >
> > typedef struct fsplit_s {
> > int fs_nfd;
> > off_t fs_off;
> > } fsplit_t;
> >
> > fcntl(fd1, F_SPLIT, &split_info);
>
> How to name the "split files" ? How to handle "file exists" ?
As above the open of fs_nfd had to already be done, so the file
exists is dealt with in the open(2) call.
> Still, having the capability could make a good case for exploring this
> possibility - "hyperfast archiving". Archive the whole contents of a
> multi-petabyte-sized filesystem snapshot in-place, one night a week...
but with snapshots and zfs backup do we really need that if it isn't
going to get it into a standard (note the small "s") archive format.
Maybe we do I don't know.
--
Darren J Moffat
_______________________________________________
ufs-discuss mailing list
[email protected]
