> 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 ?
>
> 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" ?
>
> :-) Okay I'm being silly but Casper's point is well taken fcntl(2)
> seems to be the perfect place to extend for this type of work.
Well, the devils for these things isn't the interface it's the
implementation. Performance will vary between "faster than light"
and "could've used good old cat", depending on file sizes.
Thinking a bit about the market for such things: Archiving utilities.
Both tar and cpio (and possibly others) just "concatenate" files-to-
be-archived into the archive. GNU tar has an option to move files into
archives (i.e. delete them as they are archived). If you add on-the-fly
filesystem compression (eliminating the need to '... | bzip2 >...bz2')
then fast file concatenation/split would make an interesting archiving
mechanism.
The problem of course is that none of these utilities (can) take the
blocksize thing into account, but the archive formats are to a degree
set in stone. So yes, I could see how archiving could benefit from
concat/split/compression support on filesystem level, but I think that
no existing archiving utility could really use it due to the blocksize
and alignment constraints.
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...
I'm thinking blue-sky now. But I do see why it could be interesting.
FrankH.
_______________________________________________
ufs-discuss mailing list
[email protected]
