raidframe: deleting a large file takes minutes and makes system unresponsive

[Petar Bogdanovic]

Hi,

I issued a `rm some-file-that-is-over-300gb-in-size' minutes ago and am
still waiting for rm to return.  That itself is not a problem but it
seems that the process of removing such a large file almost halts
everything else that is also doing i/o.

I noticed every once in a while that there are situations where certain
i/o-operations block everything else for a couple of seconds but it was
never as apparent as in this case.

Is it normal that a simple rm can starve everything else?

Some details:

$ mount
/dev/raid0a on / type ffs (log, NFS exported, local)

$ df -h
Filesystem Size   Used  Avail %Cap Mounted on
/dev/raid0a1.3T   970G   368G  72% /

The rm was issued on linux-laptop that mounts /dev/raid0a over NFS.  But
I guess that shouldn't make a difference.

Thanks,

Petar Bogdanovic

Re: raidframe: deleting a large file takes minutes and makes system unresponsive

[Michael van Elst]

pe...@smokva.net (Petar Bogdanovic) writes:

Is it normal that a simple rm can starve everything else?
   /dev/raid0a on / type ffs (log, NFS exported, local)

ffs logging (aka WAPBL) on raid is known to have such issues.

Re: raidframe: deleting a large file takes minutes and makes system unresponsive

[Petar Bogdanovic]

On Wed, Jan 22, 2014 at 09:07:07PM +, Michael van Elst wrote:
 pe...@smokva.net (Petar Bogdanovic) writes:
 
 Is it normal that a simple rm can starve everything else?
  /dev/raid0a on / type ffs (log, NFS exported, local)
 
 ffs logging (aka WAPBL) on raid is known to have such issues.

That's a tough one: epic fs-checks after power outages vs. mutant lags
that do this:

Jan 22 17:39:57 pintail kernel: nfs: server starling not responding, 
still trying
Jan 22 17:56:14 pintail kernel: nfs: server starling OK

But given that I'm not unlinking 300 GB files on a daily basis, lags are
probably the safer choice.