Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263639AbTKLSbK (ORCPT ); Wed, 12 Nov 2003 13:31:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264256AbTKLSbK (ORCPT ); Wed, 12 Nov 2003 13:31:10 -0500 Received: from ns.virtualhost.dk ([195.184.98.160]:14048 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S263639AbTKLSbG (ORCPT ); Wed, 12 Nov 2003 13:31:06 -0500 Date: Wed, 12 Nov 2003 19:31:05 +0100 From: Jens Axboe To: Pascal Schmidt Cc: Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt Message-ID: <20031112183105.GR21141@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1735 Lines: 45 On Wed, Nov 12 2003, Pascal Schmidt wrote: > On Tue, 11 Nov 2003, Linus Torvalds wrote: > > > Does it work if you change the order of those two things in ide-cd.c (or > > just remove the call to "cdrom_get_last_written()" entirely, so that it > > always just does the sane thing). > > I've moved the cdrom_read_capacity() to the top of cdrom_read_toc and > now the capacity gets set correctly and everything seems to work just > fine. > > dd to and from the raw device works, as do mke2fs and e2fsck. I could > also mount the disk read-write, write a 10MB file to it, and umount > again without problems. Then I rebooted into 2.4 and verified that the > filesystem is okay and the 10MB file made it to disk correctly. > > Lookin' good so far. Great! Can you please send a diff for review? It speaks more clearly than 1000 descriptions of what a patch does :) > Now, assuming there is a reason that the cdrom_read_capacity() function > is only used as a fallback for normal ide-cd devices, my change might Fall back? > break non-MO devices. I also don't know what to do when read_capacity > fails - setting capacity to 0 obviously breaks as we've seen before, > so maybe setting it to the lowest possible MO size (128M) would be a > good way to handle that situation. > > Jens, what do you think? Do what it currently does, set it to some high value? Then we'll just rely on the drive properly failing read requests. Better than not being able to reach the files. -- Jens Axboe - 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/