> > Since we have your attention - which chunks? One of the frustrations we hav
> e
> > had is the lack of feedback from anyone who has looked at XFS.
>
> o The whole vnode layer
Two answers here - economics and code stability. This is a filesystem
which has been worked on by people being payed to do so by a corporation,
therefore there is a budget (long since blown). It was simpler and hence
cheaper to wrap XFS in a conversion layer than to rework the code down
into the bowels of the filesystem. Then the stability part of it, we
started with a working filesystem, from an engineering standpoint it
made more sense to keep as much of the existing code base intact as
possible - the less surgery performed the better in terms of keeping
things running, and making it easy to take enhancements and fixes made
in the Irix base into the Linux code (we don't do it the other way around).
> o checks already peformed by the VFS all over the place
> (just take a look at xfs_rename.c!)
I think I will answer this one more slowly and in response to Al Viro's
email. But that economics/stability thing comes into it again.
> o the own quoata code
XFS quotas are transactional, when space is added to a file the quota is
adjusted in the same transaction. It is fairly hard to do this without your
own quota code.
> o the hooks for a propritary clusterfs..
Well we have to make money on something you know.... and in reality
there are not a lot of them in the filesystem.
Thanks
Steve
>
> My 2 (euro-)cents,
>
> Christoph
>
> --
> Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/