Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755474AbYF3I4Q (ORCPT ); Mon, 30 Jun 2008 04:56:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752685AbYF3Iz7 (ORCPT ); Mon, 30 Jun 2008 04:55:59 -0400 Received: from brick.kernel.dk ([87.55.233.238]:21180 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752667AbYF3Iz7 (ORCPT ); Mon, 30 Jun 2008 04:55:59 -0400 Date: Mon, 30 Jun 2008 10:55:56 +0200 From: Jens Axboe To: Zhao Forrest Cc: Boaz Harrosh , Erez Zilber , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Should a block device enforce block atomicity? Message-ID: <20080630085556.GL20826@kernel.dk> References: <20080630065525.GI20826@kernel.dk> <48689857.1050908@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1757 Lines: 41 On Mon, Jun 30 2008, Zhao Forrest wrote: > > > > Don't forget that all IO requests are queued on the device. With a > > modern HW and disk you usually have NCQ and most drives will throw > > away write request to the same sector if they see a later write to > > the same sector in the queue. > > > > That said. There is nothing wrong with writing again and again to > > the same sector on disk. File/record locking is done at the FileSystem > > level. An application that wants exclusive write need to open the file > > that way. Other wise it could even be written from another machine not > > even another thread. > > > > What is it you are concerned with? > > > I happen to read the email and have a question, that may not be Erez's > real question :) > Let's suppose the following example: > 1 pdflush find a dirty inode and decides to flush a set of dirty pages > to harddrive > 2 while this set of dirty pages is being committed to > harddrive(dma_mapping is done, but dirty pages are not really written > to disk media), application/FS is trying to update some pages in this > set of dirty pages. > > Then what happens? Will application be put into sleep until page > flushing to disk media is done? Yes, the page needs to be locked before IO can be issued. So it'll block on the page lock. That is what I referred to as the page cache providing this guarentee for you. With raw IO, the application needs to ensure ordering on its own if it commits IO to the same block more than once. -- 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/