Is NFS4.1 capable to compress files before sending them on the network
and decompress them on the destination to speed up the file transfert?
Kind regards,
Martin
On 7 April 2016 at 15:27, Martin Houry <[email protected]> wrote:
> Is NFS4.1 capable to compress files before sending them on the network
> and decompress them on the destination to speed up the file transfert?
You can get that with IP tunnel compression. Trouble is, NFS
(v2/v3/v4; and younger protocol designers are even worse by telling
you 'dunno care about high latency [ > 4 sec roundtrip ] any more'
[yeah? wanna pester? old RFS and AFS did a better job...]) are highly
sensitive to latency, and like ssh the high latency causes more
trouble than its worth.
Ced
>
> Kind regards,
> Martin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cedric Blancher <[email protected]>
Institute Pasteur
On Thu, Apr 07, 2016 at 04:06:11PM +0200, Cedric Blancher wrote:
> On 7 April 2016 at 15:27, Martin Houry <[email protected]> wrote:
> > Is NFS4.1 capable to compress files before sending them on the network
> > and decompress them on the destination to speed up the file transfert?
>
> You can get that with IP tunnel compression. Trouble is, NFS
> (v2/v3/v4; and younger protocol designers are even worse by telling
> you 'dunno care about high latency [ > 4 sec roundtrip ] any more'
> [yeah? wanna pester? old RFS and AFS did a better job...]) are highly
> sensitive to latency, and like ssh the high latency causes more
> trouble than its worth.
The only feature the protocol has that's a little bit like compression
is READ_PLUS (in 4.2), which can tell the client that a range of the
file is a hole instead of returning all the zeroes. You could think of
that as a specialized kind of compression for sparse files. Even there
we've been having some trouble ensuring there aren't performance
regressions.
--b.