| Message ID | 50AD09F0.6090706@redhat.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Wed, Nov 21, 2012 at 11:05:52AM -0600, Eric Sandeen wrote: > Although I put this in, I now think it was a bad decision. > For most users, there is very little to be done in this case. They > get the message, once per day, with no real context or proposed action. > TBH, it generates support calls when it probably does not need to; > the message sounds more dire than the situation really is. > > Just nuke it. Normal investigation via blktrace or whatnot can > reveal poor IO patterns if bad performance is encountered. I wonder if this might be a good thing to enable or disable via sysfs tuning knob, just to make it a little easier for a random application developer to test for this? And do you have a list of the bad applications so we can nag them to fix them? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/21/12 1:47 PM, Theodore Ts'o wrote: > On Wed, Nov 21, 2012 at 11:05:52AM -0600, Eric Sandeen wrote: >> Although I put this in, I now think it was a bad decision. >> For most users, there is very little to be done in this case. They >> get the message, once per day, with no real context or proposed action. >> TBH, it generates support calls when it probably does not need to; >> the message sounds more dire than the situation really is. >> >> Just nuke it. Normal investigation via blktrace or whatnot can >> reveal poor IO patterns if bad performance is encountered. > > I wonder if this might be a good thing to enable or disable via sysfs > tuning knob, just to make it a little easier for a random application > developer to test for this? *shrug* would be more knobs & more complexity; I bet 99% of people reporting it would never have known the knob was there, and doubtful they'd have turned it on. If developers cared, they'd probably have done the proper thing in the first place. I guess I'm skeptical of the usefulness. > And do you have a list of the bad applications so we can nag them to > fix them? Whenever we get it reported, it's some proprietary thing. So no, not really, I'm afraid. But google live search thinks it's virtualbox, kvm, and java ;) "Unaligned AIO/DIO on inode" turns up plenty. Can you do some sort of google-grep-awk to find every app that's been reported on lists? ;) -Eric > - Ted > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 21, 2012 at 11:05:52AM -0600, Eric Sandeen wrote: > Although I put this in, I now think it was a bad decision. > For most users, there is very little to be done in this case. They > get the message, once per day, with no real context or proposed action. > TBH, it generates support calls when it probably does not need to; > the message sounds more dire than the situation really is. > > Just nuke it. Normal investigation via blktrace or whatnot can > reveal poor IO patterns if bad performance is encountered. > > Signed-off-by: Eric Sandeen <sandeen@redhat.com> Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ext4/file.c b/fs/ext4/file.c index bf3966b..6c6b741 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -107,14 +107,6 @@ ext4_file_dio_write(struct kiocb *iocb, const struct iovec *iov, /* Unaligned direct AIO must be serialized; see comment above */ if (unaligned_aio) { - static unsigned long unaligned_warn_time; - - /* Warn about this once per day */ - if (printk_timed_ratelimit(&unaligned_warn_time, 60*60*24*HZ)) - ext4_msg(inode->i_sb, KERN_WARNING, - "Unaligned AIO/DIO on inode %ld by %s; " - "performance will be poor.", - inode->i_ino, current->comm); mutex_lock(ext4_aio_mutex(inode)); ext4_unwritten_wait(inode); }
Although I put this in, I now think it was a bad decision. For most users, there is very little to be done in this case. They get the message, once per day, with no real context or proposed action. TBH, it generates support calls when it probably does not need to; the message sounds more dire than the situation really is. Just nuke it. Normal investigation via blktrace or whatnot can reveal poor IO patterns if bad performance is encountered. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html