Bug 43269
Summary: | write block for more than 10 seconds | ||
---|---|---|---|
Product: | File System | Reporter: | amethyst623 (amethyst623) |
Component: | XFS | Assignee: | XFS Guru (xfs-masters) |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | alan, david, stern |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.32.16 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
amethyst623
2012-05-20 15:53:57 UTC
What are the xfs guys smoking? The log clearly shows what's happening. Here's the interesting part: [ 340.736000] [<822a50d4>] fsync_bdev+0x74/0xc0 [ 340.737000] [<8252e848>] printk+0x0/0x30 [ 340.738000] [<823a453e>] invalidate_partition+0x1e/0x60 [ 340.739000] [<823a4520>] invalidate_partition+0x0/0x60 [ 340.740000] [<822c2940>] del_gendisk+0x40/0x140 There's no USB error handling in there. Instead, the disk gets disconnected, the partition is invalidated, and the invalidate_partition() routine calls fsync_bdev(). That's in the block layer, not in SCSI or USB. what's your suggestion? how can I avoid the long time waiting before fwrite(or write) return? thanks. (In reply to comment #1) > What are the xfs guys smoking? The log clearly shows what's happening. > Here's > the interesting part: > > [ 340.736000] [<822a50d4>] fsync_bdev+0x74/0xc0 > [ 340.737000] [<8252e848>] printk+0x0/0x30 > [ 340.738000] [<823a453e>] invalidate_partition+0x1e/0x60 > [ 340.739000] [<823a4520>] invalidate_partition+0x0/0x60 > [ 340.740000] [<822c2940>] del_gendisk+0x40/0x140 > > There's no USB error handling in there. Instead, the disk gets disconnected, > the partition is invalidated, and the invalidate_partition() routine calls > fsync_bdev(). That's in the block layer, not in SCSI or USB. Alan (Stern), don't get you knickers in a knot because someone completely unfamiliar with USB/SCSI error handling paths mischaracterised a massive stack trace full of USB and SCSI functions leading up erroneously into the filesystem sync code. However, given you comment, I'd love to know why Alan (Cox) went and characterised this as a filesystem/XFS bug. I can't reassign it to the block layer because normal bugzilla users can't change the product field. FWIW, seeing as the person who raised this bug is now playing bugzilla bingo, here's the original XFS bz where this was raised back in january: http://oss.sgi.com/bugzilla/show_bug.cgi?id=916 I didn't mean to give the impression that I was particularly annoyed about anything. And in fact, I was surprised too to see Alan's reassignment. I would have expected it to be assigned to the block layer people. Maybe he'll do that after reading these two comments. I am not a perfect genius and master of all thing everywhere kernel. I'm just trying to clean up the bugzilla a bit and deal with stuff assigned as other/other etc. So this should go Axboe's way ? Alan It would be a good idea at least to draw his attention to this bug report. He might be able to help even if it turns out not to lie entirely within his bailiwick. |