| To: | Florian Weimer <fweimer@xxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS on 2.6.26: reading the first 4K of a large file takes ages |
| From: | Stewart Smith <stewart@xxxxxxxxxxxxxxxx> |
| Date: | Fri, 21 May 2010 16:20:46 +1000 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <82sk5m7oyz.fsf@xxxxxxxxxx> |
| References: | <8239xojfco.fsf@xxxxxxxxxx> <20100519114826.GA18224@xxxxxxxxxxxxx> <82sk5m7oyz.fsf@xxxxxxxxxx> |
| User-agent: | Notmuch/0.3.1-17-gc50524e (http://notmuchmail.org) Emacs/23.1.1 (x86_64-pc-linux-gnu) |
On Thu, 20 May 2010 12:11:00 +0000, Florian Weimer <fweimer@xxxxxx> wrote: > Thanks for confirming my hunch. I don't think it's worth fixing this > in XFS. The database should call posix_fallocate() before flushing > its internal cache to the file in essentially random order, but it's > difficult to get upstream to implement this (the source code is a bit > hard to follow, unfortunately). Which database? You could always mount with allocsize or use other tools to do the preallocation before things got too bad. -- Stewart Smith |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [PATCH] xfs: Check new inode size is OK before preallocating, Dave Chinner |
|---|---|
| Next by Date: | Re: Tuning XFS for real time audio on a laptop with encrypted LVM, Stan Hoeppner |
| Previous by Thread: | Re: XFS on 2.6.26: reading the first 4K of a large file takes ages, Florian Weimer |
| Next by Thread: | Re: XFS on 2.6.26: reading the first 4K of a large file takes ages, Florian Weimer |
| Indexes: | [Date] [Thread] [Top] [All Lists] |