On Tue, Jun 23, 2015 at 03:30:43PM -0400, Matthew Wilcox wrote:
> > I can't make any guarantees, especially not without verification. But
> > if correctly implemented any filesystems that does out of place metadata
> > writes (and that includes a traditional log) and uses checksum to ensure
> > th
On Mon, Jun 22, 2015 at 08:30:28AM +0200, Christoph Hellwig wrote:
> > Good to hear that we don't need BTT for XFS v5, can we make the
> > guarantee for all filesystems that may want to support DAX? I still
> > think stacking is a natural fit for this problem.
>
> I can't make any guarantees, esp
On Mon, Jun 22, 2015 at 02:48:48PM -0400, Jeff Moyer wrote:
> OK, so you think applications using buffered I/O will Just Work(TM)? My
> guess is that things will start to break that hadn't broken in the
> past. Sure, the application isn't designed properly, and that should be
> fixed, but we shou
Dan Williams writes:
>>> Direct I/O using application can make assumption if they know the sector
>>> size, and we must have a way for them to be able to see our new
>>> "subsector sector size".
>>
>> You need to let them determine that when NOT using the btt, yes. Right
>> now, I don't think th
On Mon, Jun 22, 2015 at 11:48 AM, Jeff Moyer wrote:
> Christoph Hellwig writes:
>
>> On Mon, Jun 22, 2015 at 12:42:44PM -0400, Jeff Moyer wrote:
>>> OK, add torn sector detection/recovery to that statement, then. More
>>> importantly, do you agree with the sentiment or not?
>>
>> I think we're g
Christoph Hellwig writes:
> On Mon, Jun 22, 2015 at 12:42:44PM -0400, Jeff Moyer wrote:
>> OK, add torn sector detection/recovery to that statement, then. More
>> importantly, do you agree with the sentiment or not?
>
> I think we're getting on a very slipper slope if we think about
> applicatio
On Mon, Jun 22, 2015 at 9:57 AM, Christoph Hellwig wrote:
> On Mon, Jun 22, 2015 at 09:54:51AM -0700, Dan Williams wrote:
>> > I don't see why you're comparing with MD and DM here. MD and DM
>> > sit cleanly ontop of any block device. If btt was independent of
>> > libnvdimm and just used ->rw_b
On Mon, Jun 22, 2015 at 09:54:51AM -0700, Dan Williams wrote:
> > I don't see why you're comparing with MD and DM here. MD and DM
> > sit cleanly ontop of any block device. If btt was independent of
> > libnvdimm and just used ->rw_bytes we could see it as this.
> >
> > But it's all a giant entan
On Mon, Jun 22, 2015 at 9:45 AM, Christoph Hellwig wrote:
> On Mon, Jun 22, 2015 at 09:36:50AM -0700, Dan Williams wrote:
>> In that case "don't stack" is too coarse of a hammer. I see this as a
>> request to hide the subordinate ULD which is a new capability that DM
>> and MD might benefit from
On Mon, Jun 22, 2015 at 12:42:44PM -0400, Jeff Moyer wrote:
> OK, add torn sector detection/recovery to that statement, then. More
> importantly, do you agree with the sentiment or not?
I think we're getting on a very slipper slope if we think about
application here. Buffered I/O application mus
On Mon, Jun 22, 2015 at 09:36:50AM -0700, Dan Williams wrote:
> In that case "don't stack" is too coarse of a hammer. I see this as a
> request to hide the subordinate ULD which is a new capability that DM
> and MD might benefit from as well. We already have the case in MD
> where it internally h
Christoph Hellwig writes:
> On Mon, Jun 22, 2015 at 12:00:54PM -0400, Jeff Moyer wrote:
>> Right now, the guidance should be to always use btt since there are no
>> applications that are directly taking advantage of persistent memory
>> (that I know). I expect documentation would take care of th
On Mon, Jun 22, 2015 at 8:40 AM, Christoph Hellwig wrote:
> On Mon, Jun 22, 2015 at 12:39:34AM -0700, Dan Williams wrote:
>> Now I'm confused, you *don't* want the raw device to be hidden *and*
>> you want to kill the stacking? Something got crossed. The current
>> implementation hides nothing,
On Mon, Jun 22, 2015 at 12:00:54PM -0400, Jeff Moyer wrote:
> Right now, the guidance should be to always use btt since there are no
> applications that are directly taking advantage of persistent memory
> (that I know). I expect documentation would take care of that. I also
> expect that, as app
Christoph Hellwig writes:
> On Mon, Jun 22, 2015 at 11:02:24AM -0400, Jeff Moyer wrote:
>> Agreed, we can't audit all code, and springing this potential data
>> corruptor on people seems irresponsible.
>
> How do "the people" know they'd have to use btt in the current setup
> without auditing the
On Mon, Jun 22, 2015 at 11:02:24AM -0400, Jeff Moyer wrote:
> Agreed, we can't audit all code, and springing this potential data
> corruptor on people seems irresponsible.
How do "the people" know they'd have to use btt in the current setup
without auditing their stack first?
--
To unsubscribe fro
On Mon, Jun 22, 2015 at 12:39:34AM -0700, Dan Williams wrote:
> Now I'm confused, you *don't* want the raw device to be hidden *and*
> you want to kill the stacking? Something got crossed. The current
> implementation hides nothing, you get to see the entire stacked
> composition. I'd much prefe
Dan Williams writes:
>> Sounds like we simply shouldn't merge btt at all for now and wait for
>> a real use case, which would simplify the whole issue a lot.
>
> The sinister aspect of sector tearing is that most applications don't
> know they have this dependency. At least today's disk's rarely
On Mon, Jun 22, 2015 at 12:28 AM, Christoph Hellwig wrote:
> On Mon, Jun 22, 2015 at 12:17:29AM -0700, Dan Williams wrote:
>> To be fair the namespace was initially envisioned to be btt enabled or
>> not, and hide the raw media device.
>
> What's the fascination with hiding one access mode just be
On Mon, Jun 22, 2015 at 12:17:29AM -0700, Dan Williams wrote:
> To be fair the namespace was initially envisioned to be btt enabled or
> not, and hide the raw media device.
What's the fascination with hiding one access mode just because
another one is available?
> There's no guarantee that these
On Sun, Jun 21, 2015 at 11:30 PM, Christoph Hellwig wrote:
> On Sun, Jun 21, 2015 at 08:11:25AM -0700, Dan Williams wrote:
>> The labels only allow allocation of persistent media between pmem and
>> blk. For a given dimm you may access in either mode and the label
>> records the decision. We can
On Sun, Jun 21, 2015 at 08:11:25AM -0700, Dan Williams wrote:
> The labels only allow allocation of persistent media between pmem and
> blk. For a given dimm you may access in either mode and the label
> records the decision. We can have a btt on either the pmem or
> blk-mode disk type, or partit
On Sun, Jun 21, 2015 at 6:54 AM, Christoph Hellwig wrote:
> On Sun, Jun 21, 2015 at 06:21:50AM -0700, Dan Williams wrote:
>> This question has come up before. Making btt an internal property of
>> a device makes some things cleaner and others more messy. We lose the
>> ability to place a btt ins
On Sun, Jun 21, 2015 at 06:21:50AM -0700, Dan Williams wrote:
> This question has come up before. Making btt an internal property of
> a device makes some things cleaner and others more messy. We lose the
> ability to place a btt instance on top of a partition, rather than a
> whole disk.
I thou
On Sun, Jun 21, 2015 at 3:13 AM, Christoph Hellwig wrote:
> On Wed, Jun 17, 2015 at 07:56:02PM -0400, Dan Williams wrote:
>> Upon detection of a read-only backing device arrange for the btt to
>> device to be read only. Implement a catch for the BLKROSET ioctl and
>> only allow a btt-instance to
On Wed, Jun 17, 2015 at 07:56:02PM -0400, Dan Williams wrote:
> Upon detection of a read-only backing device arrange for the btt to
> device to be read only. Implement a catch for the BLKROSET ioctl and
> only allow a btt-instance to become read-write when the backing-device
> becomes read-write.
On Wed, 2015-06-17 at 19:56 -0400, Dan Williams wrote:
> Upon detection of a read-only backing device arrange for the btt to
> device to be read only. Implement a catch for the BLKROSET ioctl and
> only allow a btt-instance to become read-write when the backing-device
> becomes read-write. Conver
27 matches
Mail list logo
