From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phillip Susi Subject: Re: [PATCH] Btrfs: don't panic if orphan item already exists Date: Wed, 14 Dec 2011 10:41:05 -0500 Message-ID: <4EE8C391.9090501@cfl.rr.com> References: <1323798951-4329-1-git-send-email-josef@redhat.com> <4EE7A172.2010105@cfl.rr.com> <20111213190942.GA3602@localhost.localdomain> <4EE804EB.5070209@cn.fujitsu.com> <4EE8707D.7080504@cn.fujitsu.com> <20111214145843.GA1925@localhost.localdomain> <4EE8BD45.7090809@cfl.rr.com> <20111214152638.GB1925@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Miao Xie , WuBo , linux-btrfs@vger.kernel.org To: Josef Bacik Return-path: In-Reply-To: <20111214152638.GB1925@localhost.localdomain> List-ID: On 12/14/2011 10:27 AM, Josef Bacik wrote: > Except consider the case that the program was written intelligently and checks > for errors on truncate. So he writes 100G, truncates to 50M, and the truncate > fails and he closes the file and exits. Then somewhere down the road the inode > is evicted from cache and we reboot the box. Next time the box comes up it only > looks like a 50M file, except we're still taking up 100G of disk space, and we > have no idea there's space there and it's still taken up in the allocator so it > will just look like we've lost ~100G of space. This is why it's left there, so > everything can be cleaned up. I'm a little confused here. Is there a commit somewhere in there? How can the 100g allocation be committed, but not the i_size of the inode? Shouldn't either both or neither be committed? If both are committed, and then the truncate fails, then I would expect the system to come back up after a crash with the file still at 100g. That is, as long as the orphan item is not left in place after the failed truncate.