Hello Ben,
>>The premise is that, devices whose "merge_id" is the same have
the
>>same "wwid". I think this premise can be established.
>So, if you have device where the merge_id doesn't equal the wwid, you
>call domap on that device, as it it wasn't part of a merged set?
On Thu, Jan 05, 2017 at 10:12:25PM +0100, Zdenek Kabelac wrote:
> Dne 5.1.2017 v 20:29 Eric Sandeen napsal(a):
> >On 1/5/17 1:13 PM, Zdenek Kabelac wrote:
> >>>Anyway, at this point I'm not convinced that anything but the filesystem
> >>>should be making decisions based on storage error conditions.
Hi all,
The CFP for the Linux Foundation's Vault conference is coming close to an end.
The event is being held this year in Cambridge, Massachusetts on the days
following the LSF/MM summit.
The first two year's events have been solid, focused events in my (slightly
biased) opinion, so worth
On 1/5/17 3:12 PM, Zdenek Kabelac wrote:
> Dne 5.1.2017 v 20:29 Eric Sandeen napsal(a):
>
> So if I hear all voice correctly now -
>
>
> we now want to let user continue to use such systems and let them
> figure out themself something is wrong when they get occasional write
> failure and XFS no
Dne 5.1.2017 v 20:29 Eric Sandeen napsal(a):
On 1/5/17 1:13 PM, Zdenek Kabelac wrote:
Anyway, at this point I'm not convinced that anything but the filesystem
should be making decisions based on storage error conditions.
So far I'm not convinced doing nothing is better then trying at least un
On 1/5/17 1:13 PM, Zdenek Kabelac wrote:
>> Anyway, at this point I'm not convinced that anything but the filesystem
>> should be making decisions based on storage error conditions.
>
> So far I'm not convinced doing nothing is better then trying at least
> unmount.
>
> Since doing nothing is k
I've been working on a proof-of-concept device-mapper compression
target. I'd like to discuss block-layer compression and IO hints. I'd
also be interested in attending any discussions on multipathing.
-Ben
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-
Dne 5.1.2017 v 19:24 Eric Sandeen napsal(a):
(dropping fstests list)
On 1/5/17 4:35 AM, Zdenek Kabelac wrote:
Dne 5.1.2017 v 00:03 Eric Sandeen napsal(a):
On 12/16/16 2:15 AM, Christoph Hellwig wrote:
On Thu, Dec 15, 2016 at 10:16:23AM +0100, Zdenek Kabelac wrote:
...
What XFS did on IR
On Thu, Jan 05 2017 at 1:24pm -0500,
Eric Sandeen wrote:
> Upstream now has better xfs error handling configurability. Have you
> tested with that? (for that matter, what thinp test framework exists
> on the lvm2/dm side? We currently have only minimal testing fstests,
> to be honest. Until
On 1/5/17 11:42 AM, Zdenek Kabelac wrote:
> Dne 5.1.2017 v 17:26 Mike Snitzer napsal(a):
...
>> Bottomline is lvm2 really has no business unmounting the filesystem.
>> That lvm2 "feature" should be reverted. It isn't what anyone would
>> expect. And it only serves to create problems. Nice inte
(dropping fstests list)
On 1/5/17 4:35 AM, Zdenek Kabelac wrote:
> Dne 5.1.2017 v 00:03 Eric Sandeen napsal(a):
>>
>>
>> On 12/16/16 2:15 AM, Christoph Hellwig wrote:
>>> On Thu, Dec 15, 2016 at 10:16:23AM +0100, Zdenek Kabelac wrote:
...
>>> What XFS did on IRIX was to let the volume manager ca
On Thu, Jan 05 2017 at 12:42pm -0500,
Zdenek Kabelac wrote:
> Dne 5.1.2017 v 17:26 Mike Snitzer napsal(a):
> >On Thu, Jan 05 2017 at 5:35am -0500,
> >Zdenek Kabelac wrote:
> >
> >>Dne 5.1.2017 v 00:03 Eric Sandeen napsal(a):
> >>>
> >>>
> >>>On 12/16/16 2:15 AM, Christoph Hellwig wrote:
> O
On Thu, Jan 05, 2017 at 11:10:43AM +0800, tang.jun...@zte.com.cn wrote:
>Hello Ben,
>
>I know what you concern about. Maybe we can change the "wwid" member
>in "struct uevent" to another name such as "merge_id" to only
>identify which uevents can merge together. The value of "merge
Dne 5.1.2017 v 17:26 Mike Snitzer napsal(a):
On Thu, Jan 05 2017 at 5:35am -0500,
Zdenek Kabelac wrote:
Dne 5.1.2017 v 00:03 Eric Sandeen napsal(a):
On 12/16/16 2:15 AM, Christoph Hellwig wrote:
On Thu, Dec 15, 2016 at 10:16:23AM +0100, Zdenek Kabelac wrote:
So let me explain the logic b
On Thu, Dec 29 2016 at 11:08pm -0500,
Eric Wheeler wrote:
> On Sat, 17 Dec 2016, Mike Snitzer wrote:
> > On Fri, Dec 16 2016 at 5:29pm -0500,
> > Eric Wheeler wrote:
> > > On Wed, 14 Dec 2016, Eric Wheeler wrote:
> > > > Since dm-crypt queues writes (and sometimes reads) to a different kernel
>
On Thu, Jan 05 2017 at 5:35am -0500,
Zdenek Kabelac wrote:
> Dne 5.1.2017 v 00:03 Eric Sandeen napsal(a):
> >
> >
> >On 12/16/16 2:15 AM, Christoph Hellwig wrote:
> >>On Thu, Dec 15, 2016 at 10:16:23AM +0100, Zdenek Kabelac wrote:
> >>>So let me explain the logic behind this 'amazingly stupid' i
On Thu, Jan 05, 2017 at 08:33:10AM -0500, Anthony Ryan wrote:
> When these modules are built statically into the kernel, modprobe
> will fail and prevent the service from being started. By making this
> line non-fatal, on such systems the service is still able to be
> started.
ACK
-Ben
> ---
>
When these modules are built statically into the kernel, modprobe
will fail and prevent the service from being started. By making this
line non-fatal, on such systems the service is still able to be
started.
---
multipathd/multipathd.service | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
2017-01-04 19:50 GMT+01:00 Mike Snitzer :
> On Wed, Jan 04 2017 at 12:12am -0500,
> NeilBrown wrote:
>
>> On Tue, Jan 03 2017, Jack Wang wrote:
>>
>> > 2016-12-23 12:45 GMT+01:00 Lars Ellenberg :
>> >> On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
>> >>> Dear Maintainers
>> >>>
>>
Dne 5.1.2017 v 00:03 Eric Sandeen napsal(a):
On 12/16/16 2:15 AM, Christoph Hellwig wrote:
On Thu, Dec 15, 2016 at 10:16:23AM +0100, Zdenek Kabelac wrote:
So let me explain the logic behind this 'amazingly stupid' idea.
And that logic doesn't make any sense at all. invibly unmounting
a fil
Hi Herbert,
On 2 January 2017 at 12:23, Herbert Xu wrote:
> On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote:
>
> Right. The actual number of underlying tfms that do the work
> won't change compared to the status quo. We're just structuring
> it such that if the overall scheme is sup
21 matches
Mail list logo