> On 23. Aug 2018, at 11:59, J. Hannken-Illjes wrote:
>
>
>> On 22. Aug 2018, at 08:50, Emmanuel Dreyfus wrote:
>>
>> On Mon, Aug 20, 2018 at 10:39:21AM +0200, J. Hannken-Illjes wrote:
I applied that to NetBSD-8.0, and it seems to behave much better.
>>> Good.
>>
>> Will you commit and
> On 22. Aug 2018, at 08:50, Emmanuel Dreyfus wrote:
>
> On Mon, Aug 20, 2018 at 10:39:21AM +0200, J. Hannken-Illjes wrote:
>>> I applied that to NetBSD-8.0, and it seems to behave much better.
>> Good.
>
> Will you commit and request a pullup? The change is valuable.
Sure ...
--
J. Hannken-
On Mon, Aug 20, 2018 at 10:39:21AM +0200, J. Hannken-Illjes wrote:
> > I applied that to NetBSD-8.0, and it seems to behave much better.
> Good.
Will you commit and request a pullup? The change is valuable.
--
Emmanuel Dreyfus
m...@netbsd.org
On Mon, Aug 20, 2018 at 10:39:21AM +0200, J. Hannken-Illjes wrote:
> This patch will change nothing mentioned there. As I already asked:
(...)
I was away from this machine, I wil post the answer on the relevant thread.
--
Emmanuel Dreyfus
m...@netbsd.org
> On 20. Aug 2018, at 10:34, Emmanuel Dreyfus wrote:
>
> On Thu, Aug 16, 2018 at 12:18:34PM +0200, J. Hannken-Illjes wrote:
>> - 001_add_sc_state replaces the flags FSS_ACTIVE and FSS_ERROR with
>> a state field.
>>
>> - 002_extend_state adds states for construction or destruction of
>> a snap
On Thu, Aug 16, 2018 at 12:18:34PM +0200, J. Hannken-Illjes wrote:
> - 001_add_sc_state replaces the flags FSS_ACTIVE and FSS_ERROR with
> a state field.
>
> - 002_extend_state adds states for construction or destruction of
> a snapshot and fss_ioctl no longer blocks forever waiting for
> construc
> On 14. Aug 2018, at 11:16, J. Hannken-Illjes wrote:
>
>
>> On 13. Aug 2018, at 19:25, Emmanuel Dreyfus wrote:
>>
>> On Mon, Aug 13, 2018 at 11:56:45AM +, Taylor R Campbell wrote:
>>> Unless I misunderstand fss(4), this is an abuse of mutex(9): nothing
>>> should sleep while holding the
> Date: Tue, 14 Aug 2018 11:16:44 +0200
> From: "J. Hannken-Illjes"
>
>Problem here is backwards compatibility. I have no idea what to
>return for FSSIOCGET when the state is creating or destroying.
1. It would be a small improvement if waiting to acquire the lock, at
least, were int
> On 13. Aug 2018, at 19:25, Emmanuel Dreyfus wrote:
>
> On Mon, Aug 13, 2018 at 11:56:45AM +, Taylor R Campbell wrote:
>> Unless I misunderstand fss(4), this is an abuse of mutex(9): nothing
>> should sleep while holding the lock, so that nothing trying to acquire
>> the lock will wait for
> Well, the cause is not yet completely clear to me, but the user
> experience is terrible. The first time I used it, I thought
> the system crashed, because fssconfig -l was just hung for
> hours.
My experience is that an external snapshot runs much, much faster.
It may even be the case that an
On Mon, Aug 13, 2018 at 11:56:45AM +, Taylor R Campbell wrote:
> Unless I misunderstand fss(4), this is an abuse of mutex(9): nothing
> should sleep while holding the lock, so that nothing trying to acquire
> the lock will wait for a long time.
Well, the cause is not yet completely clear to me
> Date: Fri, 10 Aug 2018 13:46:55 +
> From: Emmanuel Dreyfus
>
> Perhaps the right way is to add a FSSIOBUSY ioctl that would
> use mutex_tryenter and return EBUSY if the device is in use?
Unless I misunderstand fss(4), this is an abuse of mutex(9): nothing
should sleep while holding the loc
> On 13. Aug 2018, at 09:53, Emmanuel Dreyfus wrote:
>
> On Sun, Aug 12, 2018 at 10:16:48AM +0200, J. Hannken-Illjes wrote:
>> While creating a snapshot "/mount0" lookup "/mount0/file", it will block
>> as "/mount0" is suspended. The lookup holds a lock on "/".
>>
>> Now snapshot "/ "and tryi
On Sun, Aug 12, 2018 at 10:16:48AM +0200, J. Hannken-Illjes wrote:
> While creating a snapshot "/mount0" lookup "/mount0/file", it will block
> as "/mount0" is suspended. The lookup holds a lock on "/".
>
> Now snapshot "/ "and trying to suspend "/" will block as the lookup
> has the root vnode l
Date:Sun, 12 Aug 2018 13:25:26 +
From:Emmanuel Dreyfus
Message-ID: <20180812132526.gh17...@homeworld.netbsd.org>
| I was wondering about the FSS_ACTIVE test.
It is just one bit, either it is set, or it is not SInce the code
is already referencing sc-> (th
On Sun, Aug 12, 2018 at 04:32:49PM +0700, Robert Elz wrote:
> Clearly there's no point locking before testing for FWRITE
> in flag, that's a local var (param) to this function,
Right, that one is obvious, I was wondering about the
FSS_ACTIVE test.
> but the "if it is locked it must be active" i
Date:Sun, 12 Aug 2018 08:05:26 +
From:Emmanuel Dreyfus
Message-ID: <20180812080526.gf17...@homeworld.netbsd.org>
| Why would test then lock?
Because it avoids the overheads of acquiring a lock for no
particularly good purpose, only to immediately release it
ag
> On 12. Aug 2018, at 10:07, Emmanuel Dreyfus wrote:
>
> On Sun, Aug 12, 2018 at 09:55:27AM +0200, J. Hannken-Illjes wrote:
>>> You mean you cannot at the same tme snapshot /mount0 on fss0 and
>>> /mount1 on fss1?
>>
>> Yes, you have to create the snapshot on /mount0 and once it has been
>>
On Sun, Aug 12, 2018 at 09:55:27AM +0200, J. Hannken-Illjes wrote:
> > You mean you cannot at the same tme snapshot /mount0 on fss0 and
> > /mount1 on fss1?
>
> Yes, you have to create the snapshot on /mount0 and once it has been
> created you create the snapshot on /mount1.
Where is that limita
On Sat, Aug 11, 2018 at 10:52:42AM +0700, Robert Elz wrote:
> I doubt that your new proposed ioctl() is a very good
> interface
Indeed, the following change is enough to find a free fss without a
hang, and it does not introduce a new ioctl. It is quite close to
your proposal, except I lock bef
> On 12. Aug 2018, at 03:58, Emmanuel Dreyfus wrote:
>
> On Sat, Aug 11, 2018 at 10:33:04AM +0200, J. Hannken-Illjes wrote:
>> When fssconfig "hangs" the dump is creating a snapshot. Creating
>> a snapshot (and suspending a file system) is serialized. Allowing
>> more than one file system su
On Sat, Aug 11, 2018 at 10:33:04AM +0200, J. Hannken-Illjes wrote:
> When fssconfig "hangs" the dump is creating a snapshot. Creating
> a snapshot (and suspending a file system) is serialized. Allowing
> more than one file system suspension at a time will deadlock most
> of the time.
You mean yo
> On 10. Aug 2018, at 15:46, Emmanuel Dreyfus wrote:
>
> Hello
>
> How are user processes supposed to find an unused fss device?
> In dump(8) code, there is an iteration on /dev/rfss* trying to
> performan an ioctl FSSIOCSET. The code tests for EBUSY on failure,
> but in my experience that s
I doubt that your new proposed ioctl() is a very good
interface - to do what you really need you would require
the equivalent of a "test & set" otherwise all you are
doing is creating a race condition - even though it is,
because of the low number of users, one that is
unlikely to matter very often
Emmanuel Dreyfus wrote:
> Perhaps the right way is to add a FSSIOBUSY ioctl that would
> use mutex_tryenter and return EBUSY if the device is in use?
I propose the change below, so that we can find an available /dev/fss*
device without hanging:
--- sys/dev/fss.c.orig
+++ sys/dev/fss.c
@@ -427,8
Hello
How are user processes supposed to find an unused fss device?
In dump(8) code, there is an iteration on /dev/rfss* trying to
performan an ioctl FSSIOCSET. The code tests for EBUSY on failure,
but in my experience that struggles to happen: if the device is
already in use, the ioctl will sle
26 matches
Mail list logo