From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert W. Fuller" Subject: nobh option to ext2 Date: Sat, 01 Jan 2005 18:45:58 -0500 Message-ID: <41D73636.4080405@sbcglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from smtp802.mail.sc5.yahoo.com ([66.163.168.181]:54114 "HELO smtp802.mail.sc5.yahoo.com") by vger.kernel.org with SMTP id S261199AbVAAXqA (ORCPT ); Sat, 1 Jan 2005 18:46:00 -0500 To: linux-fsdevel@vger.kernel.org Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org I must first admit I'm a bit of a newbie. That having been said, what exactly does the nobh option to ext2 do? Perhaps you can recommend resources to me that detail the interaction between the memory manager and the file systems? I'm looking for something that means more to me than: "Implements a new set of block address_space_operations which will never attach buffer_heads to file pagecache. These can be turned on for ext2 with the `nobh' mount option. During write-intensive testing on a 7G machine, total buffer_head storage remained below 0.3 megabytes. And those buffer_heads are against ZONE_NORMAL pagecache and will be reclaimed by ZONE_NORMAL memory pressure. This work is, of course, a special for the huge highmem machines. Possibly it obsoletes the buffer_heads_over_limit stuff (which doesn't work terribly well), but that code is simple, and will provide relief for other filesystems. It should be noted that the nobh_prepare_write() function and the PageMappedToDisk() infrastructure is what is needed to solve the problem of user data corruption when the filesystem which backs a sparse MAP_SHARED mapping runs out of space. We can use this code in filemap_nopage() to ensure that all mapped pages have space allocated on-disk. Deliver SIGBUS on ENOSPC." Regards, Rob