| To: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: Questions for article |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Wed, 4 Jun 2008 01:28:59 -0400 |
| Cc: | Thomas King <kingttx@xxxxxxxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <4845C254.6050104@xxxxxxxxxxx> |
| References: | <13033.143.166.226.57.1212526129.squirrel@xxxxxxxxxxxxxxxxxxxxxxx> <4845C254.6050104@xxxxxxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.17 (2007-11-01) |
On Tue, Jun 03, 2008 at 05:14:44PM -0500, Eric Sandeen wrote: > It's also not clear to me that this is really a critical feature for > large filesystems; space allocation is not done block by block per se in > xfs, as Mr. Newman seems (?) to imply (?) The block granularity is > there throughout the fs but I'm not sure how much it matters in > practice. Dave...? For streaming I/O workloads it doesn't matter anymore, see Dave's 2006 OLS talk. The direct to bio I/O path mitigates any blocksize impact. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: DMAPI JFS bug fixes, Eric Sandeen |
|---|---|
| Next by Date: | Re: Questions for article, Christoph Hellwig |
| Previous by Thread: | Re: Questions for article, Thomas King |
| Next by Thread: | Re: Questions for article, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |