| To: | xfs@xxxxxxxxxxx |
|---|---|
| Subject: | Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs |
| From: | Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> |
| Date: | Thu, 05 Aug 2010 03:33:17 -0500 |
| In-reply-to: | <20100805082438.0b476adb@notabene> |
| References: | <20100804073546.GA7494@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20100804085039.GA11671@xxxxxxxxxxxxx> <20100804091317.GA27779@xxxxxxxxxxxxxxxxxx> <20100804092122.GA2998@xxxxxxxxxxxxx> <20100804073546.GA7494@xxxxxxxxxxxxxxxxxxxxxxxxxx> <201008041116.09822@xxxxxx> <20100804102526.GB13766@xxxxxxxxxxxxxxxxxx> <20100804111803.GA32643@xxxxxxxxxxxxx> <alpine.DEB.1.10.1008041351100.19930@xxxxxxxxxxxxxxxx> <20100805082438.0b476adb@notabene> |
| User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 |
Neil Brown put forth on 8/4/2010 5:24 PM: > Both page-cache and read-ahead work at the filesystem level Are you referring to /sys/block/sdx/queue/read_ahead_kb? I'm pretty sure this works below the FS level and below the partition level. This read_ahead works at the block device level. At least for individual or JBOD. Are you saying this setting gets ignored by the kernel if/when mdadm, LVM, and/or crypto are used? -- Stan |
| Previous by Date: | Re: XFS hung on 2.6.33.3 kernel, Ilia Mirkin |
|---|---|
| Next by Date: | direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs], Dominik Brodowski |
| Previous by Thread: | Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs, Neil Brown |
| Next by Thread: | Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |