lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 30 Jun 2008 10:55:56 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Zhao Forrest <forrest.zhao@...il.com>
Cc:	Boaz Harrosh <bharrosh@...asas.com>,
	Erez Zilber <erezzi.list@...il.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Should a block device enforce block atomicity?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ