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: Thu, 02 May 2013 14:12:45 +0900 Message-ID: <87vc722cdu.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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp 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 "Thu, 2 May 2013 13:46:00 +0900") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Namjae Jeon writes: >>>> Hm, why d_count == 1 check is needed? Feel strange and racy. >>> Since, fat_file_release() is called on every close for the file. >> >> What is wrong? IIRC, it is what you choose (i.e. for each last close for >> the file descriptor). > Yes, this is what we had chosen after discussion. Freeing reserved > space point being the file release path. > But if there are multiple accessors for the file then file_release > will be called by each process. > Freeing the space in first call will result in wrong file attributes > for the other points. So, we needed a differentiation of last close > for the file. > Am I missing something ? Then, per-file discard fallocate space sounds like wrong. fallocate space probably is inode attribute. >> I know. Question is, why do we need to initialize twice. >> >> 1) zeroed for uninitialized area, 2) then copy user data area. We need >> only either, right? This seems to be doing both for all fallocated area. > We did not initialize twice. We are using the ‘pos’ as the attribute > to define zeroing length in case of pre-allocation. > Zeroing out occurs till the ‘pos’ while actual write occur after ‘pos’. > If we file size is 100KB and we pre-allocated till 1MB. Next if we try > to write at 500KB, > Then zeroing out will occur only for 100KB->500KB, after that there > will be normal write. There is no duplication for the same space. Ah. Then write_begin() really initialize after i_size until page cache boudary for append write? I wonder if this patch works correctly for mmap. Thanks. -- OGAWA Hirofumi