This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 19:24:13 2024 Delivery-date: Tue, 28 Feb 2006 14:14:46 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750752AbWB1NKt (ORCPT ); Tue, 28 Feb 2006 08:10:49 -0500 Received: from spirit.analogic.com ([204.178.40.4]:3856 "EHLO spirit.analogic.com") by vger.kernel.org with ESMTP id S1750747AbWB1NKs convert rfc822-to-8bit (ORCPT ); Tue, 28 Feb 2006 08:10:48 -0500 Received: from chaos.analogic.com ([10.112.50.11]) by phoenix.analogic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 08:10:44 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from chaos.analogic.com (localhost [127.0.0.1]) by chaos.analogic.com (8.12.11/8.12.11) with ESMTP id k1SDAiEe009327; Tue, 28 Feb 2006 08:10:44 -0500 Received: (from linux-os@localhost) by chaos.analogic.com (8.12.11/8.12.11/Submit) id k1SDAiFS009326; Tue, 28 Feb 2006 08:10:44 -0500 In-Reply-To: X-OriginalArrivalTime: 28 Feb 2006 13:10:45.0026 (UTC) FILETIME=[624F3020:01C63C68] content-class: urn:content-classes:message Subject: Re: o_sync in vfat driver Date: Tue, 28 Feb 2006 08:10:44 -0500 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: o_sync in vfat driver Thread-Index: AcY8aGJYTphCxiy2SjmLRhVMbaTkzg== References: To: Cc: Reply-To: "linux-os \(Dick Johnson\)" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 27 Feb 2006 col-pepper@piments.com wrote: > On Mon, 27 Feb 2006 22:32:07 +0100, linux-os (Dick Johnson) > wrote: > >> Flash does not get zeroed to be written! It gets erased, which sets all >> the bits to '1', i.e., all bytes to 0xff. > > Thanks for the correction, but that does not change the discussion. > >> Further, the designers of >> flash disks are not stupid as you assume. The direct access occurs >> to static RAM (read/write stuff). > > I'm not assuming anything . Some hardware has been killed by this issue. > http://lkml.org/lkml/2005/5/13/144 No. That hardware was not killed by that issue. The writer, or another who had encountered the same issue, eventually repartitioned and reformatted the device. The partition table had gotten corrupted by some experiments and the writer assumed that the device was broken. It wasn't. Also, if you read other elements in this thread, you would have learned about something that has become somewhat of a red herring. It takes about a second to erase a 64k physical sector. This is a required operation before it is written. Since the projected life of these new devices is about 5 to 10 million such cycles, (older NAND flash used in modems was only 100-200k) the writer would have to be running that "brand new device" for at least 5 million seconds. Let's see: 60 seconds per minute 3600 seconds per hour 86400 seconds per day. 5,000,000 / 86400 = 57 days of continuous writes to the same sector. The writer surely would have a strange file because he states that even a single large file can destroy the drive if it is mounted with the "sync" option. Also, the failure mode of NAND flash is not that it becomes "destroyed". The failure mode is a slow loss of data. The devices no longer retain data for a zillion years, only a few hundred, eventually, only a year or so. So when somebody claims that the flash has gotten destroyed, they need to have written it for a few months, then waited for a few years before reporting the event. Clearly the writer is wrong. > > It seems that it's you making the assumption that all of these devices are > manufactured the same way. > > The constant dirtying of the buffer will still cause excessive use of the > flash block hosting the FAT. Clearly not all devices use a load spreading > mechanism and this can lead to premature failure. > Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.53 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _  **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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/