> On 14. Aug 2018, at 11:16, J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote: > > >> On 13. Aug 2018, at 19:25, Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote: >> >> On Mon, Aug 13, 2018 at 11:56:45AM +0000, 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, 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. >> >> And it is very easy to acheive a situation where most processes >> are in tstile awaiting a vnode lock for a name lookup. > > I see two problems here. > > 1) File system internal snapshots take long to create or destroy on > large file systems. I have no solution to this problem. > > Using file system external snapshots for dumps should work fine. > > 2) Fss devices block in ioctl while a snapshot gets created or > destroyed. A possible fix is to replace the current > active/non-active state with idle/creating/active/destroying <snip> The attached diffs implement this in a pullup-friendly way. - 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 construction or destruction of a snapshot to complete. Opinions? -- J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)
Attachment:
001_add_sc_state
Description: Binary data
Attachment:
002_extend_state
Description: Binary data