On Monday May 8, [email protected] wrote:
> NACK. As long as we have no HSM support in the tree there's no reason to
> add this. From the kernel's point it's just untested and unused code that
> can break.
Greg: you seemed to suggest that there was already code in XFS that
could make use of this. If that is so: could you point us to it
please.
Alternately, if this will only be used by future patches, please feel
free to add this patch to that set, and add
Acked-By: NeilBrown <[email protected]>
to it.
Thanks,
NeilBrown
On Tue, 2006-05-09 at 03:55, Christoph Hellwig wrote:
> On Mon, May 08, 2006 at 09:16:34PM +1000, Neil Brown wrote:
> > On Monday May 8, [email protected] wrote:
> > > NACK. As long as we have no HSM support in the tree there's no reason to
> > > add this. From the kernel's point it's just untested and unused code that
> > > can break.
So your only objection is the absence of DMAPI or some equivalent?
If so, perhaps the best way forward in the short term is for SUSE
to add it as an out-of-tree patch.
> > Greg: you seemed to suggest that there was already code in XFS that
> > could make use of this. If that is so: could you point us to it
> > please.
>
> It's used by SGI's out of tree dmapi implementation. Because dmapi is such
> an utterly braindead standard
Sure it's ugly, but to be fair it's no worse than SysV semaphores
and shmem, and it does fill a real (albeit niche) need which nothing
else does AFAIK. Compare to TLI, which is pretty much entirely useless.
> I don't expect anyone to submit a kernel-based
> implementation for inclusion, although support for a big enough subset of
> that standard could be archived by proper kernel <-> userspace cooperation.
I don't understand what you mean here: surely almost all of what
DMAPI specifies is for achieving proper kernel/userspace co-operation?
Do you have some ideas for a better way of doing that?
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
On Tue, May 09, 2006 at 12:35:15PM +1000, Greg Banks wrote:
> So your only objection is the absence of DMAPI or some equivalent?
> If so, perhaps the best way forward in the short term is for SUSE
> to add it as an out-of-tree patch.
The objection doesn't have anything to do with DMAPI per see. It has to
do with adding kernel code that's never used in tree and thus bloats the
kernel. Also it has a fair chance to bitrot as there's no way it can be
tested.
p.s. -fsdevel couldn't care less about what patches you send to SuSE,
please stop posting such things here and talk to your SuSE technical contacts.
> Sure it's ugly, but to be fair it's no worse than SysV semaphores
> and shmem, and it does fill a real (albeit niche) need which nothing
> else does AFAIK. Compare to TLI, which is pretty much entirely useless.
It's fat worse because it makes assumptions that simply aren't true in
a unix or linux enviroment. SysV IPC is ugly but doesn't do this.
> > I don't expect anyone to submit a kernel-based
> > implementation for inclusion, although support for a big enough subset of
> > that standard could be archived by proper kernel <-> userspace cooperation.
>
> I don't understand what you mean here: surely almost all of what
> DMAPI specifies is for achieving proper kernel/userspace co-operation?
no. the DMAPI spec doesn't even know about the user <-> kernel boundary
nor should it.
> Do you have some ideas for a better way of doing that?
Yes, and I've written them up quite a few times, please look at the fsdevel
linux-kernel archives and possible some SGI-internal lists from years ago.
On Mon, May 08, 2006 at 09:16:34PM +1000, Neil Brown wrote:
> On Monday May 8, [email protected] wrote:
> > NACK. As long as we have no HSM support in the tree there's no reason to
> > add this. From the kernel's point it's just untested and unused code that
> > can break.
>
> Greg: you seemed to suggest that there was already code in XFS that
> could make use of this. If that is so: could you point us to it
> please.
The code in question is in fs/xfs/linux-2.6/xfs_iops.c::xfs_vn_setattr,
fs/xfs/xfs_dmapi.h::AT_DELAY_FLAG, and its users in xfs_setattr and
xfs_free_file_space and one or two other spots in XFS. The DMAPI code
(driver, outside XFS) can be found in the XFS CVS tree on oss.sgi.com.
> Alternately, if this will only be used by future patches, please feel
> free to add this patch to that set, and add
The DMAPI code was released at the same time as XFS, but it seems to
be a spec that is not widely used (unsurprising since not may people
have tape robots doing their bidding) and, perhaps more importantly,
its not viewed as a particularly clean spec by, erm, certain kernel
developers. ;)
cheers.
--
Nathan
On Mon, May 08, 2006 at 09:16:34PM +1000, Neil Brown wrote:
> On Monday May 8, [email protected] wrote:
> > NACK. As long as we have no HSM support in the tree there's no reason to
> > add this. From the kernel's point it's just untested and unused code that
> > can break.
>
>
> Greg: you seemed to suggest that there was already code in XFS that
> could make use of this. If that is so: could you point us to it
> please.
It's used by SGI's out of tree dmapi implementation. Because dmapi is such
an utterly braindead standard I don't expect anyone to submit a kernel-based
implementation for inclusion, although support for a big enough subset of
that standard could be archived by proper kernel <-> userspace cooperation.