Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932630AbZKMX2y (ORCPT ); Fri, 13 Nov 2009 18:28:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932580AbZKMX2u (ORCPT ); Fri, 13 Nov 2009 18:28:50 -0500 Received: from mail.vyatta.com ([76.74.103.46]:57471 "EHLO mail.vyatta.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932557AbZKMX2m (ORCPT ); Fri, 13 Nov 2009 18:28:42 -0500 Date: Fri, 13 Nov 2009 15:28:21 -0800 From: Stephen Hemminger To: Andrew Morton Cc: Frans Pop , Frederic Weisbecker , Nick Piggin , jens.axboe@oracle.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: Mount -o sync regression in 2.6.31 Message-ID: <20091113152821.2d712997@nehalam> In-Reply-To: <20091113150719.9d31dde2.akpm@linux-foundation.org> References: <20091111123340.703f5c86@nehalam> <200911112234.24180.elendil@planet.nl> <20091113144727.575cf038@nehalam> <20091113150719.9d31dde2.akpm@linux-foundation.org> Organization: Vyatta X-Mailer: Claws Mail 3.6.1 (GTK+ 2.16.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4319 Lines: 92 On Fri, 13 Nov 2009 15:07:19 -0800 Andrew Morton wrote: > On Fri, 13 Nov 2009 14:47:27 -0800 > Stephen Hemminger wrote: > > > Okay the scenario is: > > 1. Mount floppy with ext2 filesystem in sync mode > > 2. Write to floppy > > 3. Prematurely eject floppy > > 4. Unmount floppy > > I assume that by "prematurely eject", you mean that you waited until > the activity LED had turned off, then hit the button without typing > umount? yes. no activity, but not unmounted > > Really, I think ext2 is just wrong here. At unmount time it runs > ext2_sync_super(), which updates a few fields in the superblock and > tries to write them back. > > But if the fs was mounted with `-osync' then the driver should be > operating synchronously, dammit! That means that any time any syscall > alters the filesystem's s_free_blocks_count, s_free_inodes_count or > s_wtime, the driver should write those fields back to the superblock > prior to returning from the syscall. Agreed, but it looks like it has always done that. > However that might be unreasonaly anal of us, because those fields > aren't terribly important. A fsck will whine and fix them up. > > > This triggers this warning in 2.6.31 which did not occur in 2.6.30 > > hm, I wonder why that changed. The warning's been there for a while. > > > [ 580.325447] floppy0: disk absent or changed during operation > > [ 580.325454] lost page write due to I/O error on fd0 > > [ 580.958434] ------------[ cut here ]------------ > > [ 580.958437] WARNING: at fs/buffer.c:1152 mark_buffer_dirty+0x23/0x7d() > > [ 580.958440] Hardware name: System Product Name > > [ 580.958442] Modules linked in: hid_belkin binfmt_misc bridge stp llc kvm_intel kvm ipv6 video output pci_slot acpi_cpufreq cpufreq_powersave cpufreq_ondemand cpufreq_conservative cpufreq_userspace psmouse pcspkr serio_raw rtc_cmos wmi evdev sg sr_mod cdrom usbhid mvsas pata_acpi pata_marvell ata_piix libsas ahci igb sky2 scsi_transport_sas dca e1000e floppy dm_mirror dm_region_hash dm_log dm_snapshot dm_mod fuse > > [ 580.958475] Pid: 8340, comm: umount Not tainted 2.6.30-rc6-bisect #12 > > [ 580.958477] Call Trace: > > [ 580.958483] [] ? warn_slowpath_fmt+0xd9/0x10b > > [ 580.958489] [] ? find_get_pages_tag+0x41/0xdd > > [ 580.958494] [] ? pagevec_lookup+0x17/0x1e > > [ 580.958498] [] ? truncate_inode_pages_range+0x21d/0x31d > > [ 580.958502] [] ? wait_on_page_writeback_range+0xce/0x11b > > [ 580.958507] [] ? bit_waitqueue+0x10/0xa0 > > [ 580.958510] [] ? mark_buffer_dirty+0x23/0x7d > > [ 580.958515] [] ? ext2_sync_super+0x39/0x55 > > [ 580.958519] [] ? ext2_put_super+0x34/0xc7 > > [ 580.958524] [] ? generic_shutdown_super+0x70/0xfd > > [ 580.958533] [] ? kill_block_super+0x22/0x3a > > [ 580.958537] [] ? deactivate_super+0x43/0x5a > > [ 580.958541] [] ? sys_umount+0x2d8/0x307 > > [ 580.958546] [] ? system_call_fastpath+0x16/0x1b > > [ 580.958549] ---[ end trace ccbde6411acd243f ]--- > > [ 580.958580] floppy0: disk absent or changed during operation > > [ 580.958587] lost page write due to I/O error on fd0 > > void mark_buffer_dirty(struct buffer_head *bh) > { > WARN_ON_ONCE(!buffer_uptodate(bh)); > > that's expected, I expect. And it's just a WARN_ON_ONCE() so it > won't be flooding logs. We could just delete it I suppose. > > > Bisecting between 2.6.30 and 2.6.31-rc1 reduced it down to: > > > > 8f184f27300f66f6dcc8296c2dae7a1fbe8429c9 is first bad commit > > commit 8f184f27300f66f6dcc8296c2dae7a1fbe8429c9 > > Author: Frederic Weisbecker > > Date: Sat May 16 06:24:36 2009 +0200 > > > > tracing/stat: replace linked list by an rbtree for sorting > > Current score: > > git: 4,559 > kernel developers: 0 -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/