From mboxrd@z Thu Jan 1 00:00:00 1970 From: OGAWA Hirofumi Subject: Re: [PATCH RESEND v5] fat: editions to support fat_fallocate Date: Wed, 19 Jun 2013 02:33:01 +0900 Message-ID: <87txkvjpde.fsf@devron.myhome.or.jp> References: <1367107703-2665-1-git-send-email-linkinjeon@gmail.com> <87ppxd4ddm.fsf@devron.myhome.or.jp> <87bo8v42wx.fsf@devron.myhome.or.jp> <87vc722cdu.fsf@devron.myhome.or.jp> <87r4hp3kax.fsf@devron.myhome.or.jp> <87k3nh3jzi.fsf@devron.myhome.or.jp> <87fvy53eun.fsf@devron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Namjae Jeon , Amit Sahrawat To: Namjae Jeon Return-path: In-Reply-To: (Namjae Jeon's message of "Tue, 18 Jun 2013 14:47:10 +0900") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Namjae Jeon writes: >>If above is correct, right implement to change get_block(). > Now when we try to write in the fallocated region ( with keep size) in > the fat_write_begin when it is called first time it checks that the > mismatch is present between the mmu_private and mmu_actual , and hence > zero out the region ; since buffer_new is not set for fallocated > region by fat_get_block , we explicitly zero out the lseeked region > using "fat_zero_falloc_area" and normal write occurs beyond that , and > i_size is updated accordingly , and as such there is no need to move > the code to fat_get_block . OK. So, like I said, you *changed* the behavior of get_block() via fallocate() change, right? (I think, now, you noticed fat_get_block() was changed.) Since you changed the behavior of get_block(), you had to hack write_begin(). (IMO, that patch is dirty hack to fix write_begin() path only) Likewise, you have to prove all callers of get_block() must work collectedly with that change. What happen on direct I/O, bmap ioctl, etc.? Well, anyway, please fix the root cause of change of behavior. Thanks. -- OGAWA Hirofumi