> 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
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
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
>
> 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
> 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
> 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
> 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
> 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
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
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->
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
> 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
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
> 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
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
> 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
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
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
@@
21 matches
Mail list logo
