From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: [RFC] Draft Linux kernel interfaces for ZBC drives Date: Mon, 3 Feb 2014 16:38:36 -0500 Message-ID: <20140203213836.GB22856@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Jeff Moyer Return-path: Received: from imap.thunk.org ([74.207.234.97]:53862 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752913AbaBCVik (ORCPT ); Mon, 3 Feb 2014 16:38:40 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Feb 03, 2014 at 04:01:15PM -0500, Jeff Moyer wrote: > "Theodore Ts'o" writes: > > > * We can also further shrink the structure by removing the > > * z_checkpoint_offset element, since most of the time > > * z_write_ptr_offset and z_checkpoint_offset will be the same. The > > * only time they will be different is after a write is interrupted > > * via an unexpected power removal > > This may fall into the nit-picking category, but at runtime I'd expect > the write pointer and the checkpoint lba to be different more often than > not, unless you're doing all FUA writes, or are issuing flushes after > every write. Sure, but the only time we care is after an unexpected power removal, and I would expect that shortly after the system is rebooted, the file system or userspace storage space application would want to take care of dealing with recovery right away. So I'm not really proposing to track the z_checkpoint_offset except report writes to the storage device that might have failed due to power failures, since presumably this is the only time users of this interface would care. - Ted