From: Amir Goldstein Subject: Re: [LSF/FS TOPIC] Ext4 snapshots status update Date: Wed, 30 Mar 2011 12:46:24 +0200 Message-ID: References: <20110204002043.GA15658@noexit> <20110330003429.GA32669@noexit> <4D92C508.7010404@tao.ma> <20110330103321.GB1564@noexit> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Tao Ma , linux-fsdevel , Ext4 Developers List , Theodore Tso , Chris Mason , Josef Bacik To: Joel Becker Return-path: In-Reply-To: <20110330103321.GB1564@noexit> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Wed, Mar 30, 2011 at 12:33 PM, Joel Becker wrot= e: > On Wed, Mar 30, 2011 at 08:05:38AM +0200, Amir Goldstein wrote: >> Just wanted to clarify there are 2 differences I notice between mmap >> write to a hole >> and mmap write to COWed file with ENOSPC: >> >> 1. A "good" application can avoid mmap write to a hole. >> >> 2. when initiating a hole, the mkwrite callback is in used (in ext4)= to >> reserve disk space for delayed allocation when a page becomes writab= le. >> with COW a page may already be writable when the flush encounters CO= W >> with ENOSPC. that flush can even happen after the application has ex= ited, >> so the data will be dropped on the floor silently (like in ext3). > > =A0 =A0 =A0 =A0ocfs2 doesn't have delayed allocation yet, so we try a= nd fail > the allocation in write_begin() right under mkwrite(). > And what if the page is already writable? Do you go over all inode pages and make them RO after fastcopy? =46or volume level snapshot this isn't a sensible option. Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html