| To: | Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: deadlock with fallocate |
| From: | Thomas Neumann <tneumann@xxxxxxxxxxxxxxxxxxxxx> |
| Date: | Sun, 11 Oct 2009 10:53:56 +0200 |
| Cc: | linux-kernel@xxxxxxxxxxxxxxx, xfs-masters@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxx> |
| In-reply-to: | <20091011005746.56cd3cd4.akpm@xxxxxxxxxxxxxxxxxxxx> |
| References: | <hah08m$p1a$1@xxxxxxxxxxxxx> <20091011005746.56cd3cd4.akpm@xxxxxxxxxxxxxxxxxxxx> |
| User-agent: | KMail/1.11.4 (Linux/2.6.28-15-generic; KDE/4.2.4; x86_64; ; ) |
> Will legacy applications fail on newer kernels? Or is it the case that > only recently-written applications which utilise new kernel > functionality will hit this bug? In theory posix_fallocate has been around for a while and glibc will use kernel functionality if available, so applications might break. In practice it is perhaps not that common that applications use fallocate. The problem is definitively fallocate related. When I replace possix_fallocate with the equivalent ftruncate64 call the problem goes away. (But then again the two calls are not really equivalent, and fallocate is the semantic that I need). Furthermore the deadlocks seem to start occurring after writing more data than available main memory, but I did not investigate this thoroughly. Thomas |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: deadlock with fallocate, Andrew Morton |
|---|---|
| Next by Date: | Re: deadlock with fallocate, Christoph Hellwig |
| Previous by Thread: | Re: deadlock with fallocate, Andrew Morton |
| Next by Thread: | Re: deadlock with fallocate, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |