co...@sdf.org writes:
I too was not happy about the notion that librefuse should be
deprecated.
> librefuse is matching the newer FUSE APIs. it's not matching the older.
> The filesystems want the older high-level API.
I have looked into this slightly. I had the impression from the list
that fi
I'm merely upset that the people who are currently calling for librefuse
to be deleted ignore all the complaints about things being dysfunctional
until the very moment I decide to do something about librefuse, because
I didn't pick their preferred way of doing things.
(Even now, nobody seems to car
On Fri, Apr 12, 2019 at 03:46:15AM +0200, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon wrote:
>
> > Gluster on Linux hitting 9Gb/sec for sequential I/O
>
> Well at that performance level, avoiding copies is certainly a must, but
> I cannot test that because I lack the hardware (10G ethernet for
Thor Lancelot Simon wrote:
> Gluster on Linux hitting 9Gb/sec for sequential I/O
Well at that performance level, avoiding copies is certainly a must, but
I cannot test that because I lack the hardware (10G ethernet for that
slide?)
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On Fri, Apr 12, 2019 at 01:55:39AM +0200, Emmanuel Dreyfus wrote:
>
> On the performance front, it is true that the perfuse stack will cause
> data to be copied back and forth. When I started it, I thought that I
> would quickly have to add shared memory tricks to avoid copying data,
> but it has
Greg Troxel wrote:
> Do you think that (for things that use the high-level API) it is
> better to use (upstream, via pkgsrc) libfuse and perfuse, instead of
> using librefuse? If so, could you explain why? It seems to me to add
> a layer of indirection and a daemon.
Indeed, I think tha
m...@netbsd.org (Emmanuel Dreyfus) writes:
> wrote:
>
>> I'm just going to commit code without code review if all the responses
>> are going to be "please don't work on X, work on Y instead".
>> I am interested in librefuse because that's what gets used.
>
> Sure, go ahead for the short term, but
wrote:
> I'm just going to commit code without code review if all the responses
> are going to be "please don't work on X, work on Y instead".
> I am interested in librefuse because that's what gets used.
Sure, go ahead for the short term, but my point is that in the long run,
your life could be
Taylor R Campbell writes:
>> Date: Wed, 10 Apr 2019 19:50:02 +
>> From: co...@sdf.org
>> I'm just going to commit code without code review if all the responses
>> are going to be "please don't work on X, work on Y instead".
>> I am interested in librefuse because that's what gets used.
>
>
On Wed, Apr 10, 2019 at 10:19:38PM +, Taylor R Campbell wrote:
> > Date: Wed, 10 Apr 2019 19:50:02 +
> > From: co...@sdf.org
> >
> > On Wed, Apr 10, 2019 at 08:55:05PM +0200, Emmanuel Dreyfus wrote:
> > > wrote:
> > >
> > > > If anything we should get rid of perfuse.
> > >
> > > FUSE ha
> Date: Wed, 10 Apr 2019 19:50:02 +
> From: co...@sdf.org
>
> On Wed, Apr 10, 2019 at 08:55:05PM +0200, Emmanuel Dreyfus wrote:
> > wrote:
> >
> > > If anything we should get rid of perfuse.
> >
> > FUSE has thee API: kernel level, low level and high level.
> >
> > refuse only implements t
On Wed, Apr 10, 2019 at 08:55:05PM +0200, Emmanuel Dreyfus wrote:
> wrote:
>
> > If anything we should get rid of perfuse.
>
> FUSE has thee API: kernel level, low level and high level.
>
> refuse only implements the high level API
>
> perfuse implements the kernel API, libfuse runs on top of
wrote:
> If anything we should get rid of perfuse.
FUSE has thee API: kernel level, low level and high level.
refuse only implements the high level API
perfuse implements the kernel API, libfuse runs on top of it and
provides low level API and high level API. `
Hence, perfuse supports all FUS
co...@sdf.org writes:
> No, upstream FUSE loves having every downstream filesystem get adjusted
> whenever it decides an argument isn't useful any more.
So you are proposing to provide more compat than mainstream fuse, and we
would add a -D argument to packages that need it, on NetBSD only, and
t
On Wed, Apr 10, 2019 at 12:44:44PM -0400, Greg Troxel wrote:
> co...@sdf.org writes:
>
> > If anything we should get rid of perfuse.
>
> Certainly not. It is there because gluster uses /dev/fuse directly, or
> via some "low level" API, rather than using the standard FUSE API (the
> "high level"
On Wed, Apr 10, 2019 at 12:46:57PM -0400, Greg Troxel wrote:
> co...@sdf.org writes:
>
> > On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote:
> >>
> >> +#if FUSE_USE_VERSION < 30
> >> +#define fuse_unmount fuse_unmount_compat30
> >> +#endif
> >
> > Open to (FUSE_USE_VERSION < 30) &&
co...@sdf.org writes:
> On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote:
>>
>> +#if FUSE_USE_VERSION < 30
>> +#define fuse_unmount fuse_unmount_compat30
>> +#endif
>
> Open to (FUSE_USE_VERSION < 30) && (FUSE_USE_VERSION > 22) :-)
Don't you need defined(FUSE_USE_VERSION) also? Or
co...@sdf.org writes:
> If anything we should get rid of perfuse.
Certainly not. It is there because gluster uses /dev/fuse directly, or
via some "low level" API, rather than using the standard FUSE API (the
"high level" API). I am unclear on why, but my impression is that there
are good reason
On Wed, Apr 10, 2019 at 12:23:28PM -0400, Greg Troxel wrote:
> co...@sdf.org writes:
>
> > On Wed, Apr 10, 2019 at 02:22:22PM +, Emmanuel Dreyfus wrote:
> >> On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote:
> >> > Tell me what you think. I will commit it soon otherwise.
> >>
> >
co...@sdf.org writes:
> On Wed, Apr 10, 2019 at 02:22:22PM +, Emmanuel Dreyfus wrote:
>> On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote:
>> > Tell me what you think. I will commit it soon otherwise.
>>
>> You know we support vnilla libfuse through libperfuse, right?
>>
>> --
On Wed, Apr 10, 2019 at 02:22:22PM +, Emmanuel Dreyfus wrote:
> On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote:
> > Tell me what you think. I will commit it soon otherwise.
>
> You know we support vnilla libfuse through libperfuse, right?
>
> --
> Emmanuel Dreyfus
> m...@netbs
On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote:
> Tell me what you think. I will commit it soon otherwise.
You know we support vnilla libfuse through libperfuse, right?
--
Emmanuel Dreyfus
m...@netbsd.org
On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote:
>
> +#if FUSE_USE_VERSION < 30
> +#define fuse_unmount fuse_unmount_compat30
> +#endif
Open to (FUSE_USE_VERSION < 30) && (FUSE_USE_VERSION > 22) :-)
hi folks,
this adds the version of fuse_mount, fuse_new, fuse_unmount between FUSE
2.2 and FUSE 3.0 as compat shims.
This is used by fuse-ntfs-3g, fuse-encfs.
This also adds fuse_version. This is used by fuse-ext2 that is being
patched in pkgsrc.
Tell me what you think. I will commit it soon ot
24 matches
Mail list logo
