On Mon, Jan 09, 2017 at 08:54:02AM -0600, Eric Sandeen wrote:
> On 1/9/17 8:22 AM, Zdenek Kabelac wrote:
> > But could anyone from XFS specify - why umount is causing some
> > 'more' damage, then no umount at all ?
>
> Please reread this thread... it /started/ with problems
> /caused by unmoun
On Mon, Jan 09, 2017 at 04:11:08PM +0100, Zdenek Kabelac wrote:
>
> You have the case were application will write to 'different' filesystem,
> while in other cases user will be able to continue to use their filesystem
> and cause irreparable filesystem damage (whatever you want to believe
> is fai
On Mon, Jan 09, 2017 at 03:22:00PM +0100, Zdenek Kabelac wrote:
> lvm2 will initiate lazy umount of ALL thin devices from a thin-pool
> when it gets about 95% fullness (so it's a bit sooner then 100%
> with still some 5% 'free-space'.
Yes, and we want this not to be done. Not for XFS and not for
Dne 9.1.2017 v 15:54 Eric Sandeen napsal(a):
On 1/9/17 8:22 AM, Zdenek Kabelac wrote:
But could anyone from XFS specify - why umount is causing some
'more' damage, then no umount at all ?
Please reread this thread... it /started/ with problems
/caused by unmount/ for Christoph.
It's not t
On 1/9/17 8:22 AM, Zdenek Kabelac wrote:
> But could anyone from XFS specify - why umount is causing some
> 'more' damage, then no umount at all ?
Please reread this thread... it /started/ with problems
/caused by unmount/ for Christoph.
It's not that unmount damages the filesystem per se; it
Dne 9.1.2017 v 14:39 Christoph Hellwig napsal(a):
On Fri, Jan 06, 2017 at 09:46:00AM +1100, Dave Chinner wrote:
And my 2c worth on the "lvm unmounting filesystems on error" - stop
it, now. It's the wrong thing to do, and it makes it impossible for
filesystems to handle the error and recover grac
On Fri, Jan 06, 2017 at 09:46:00AM +1100, Dave Chinner wrote:
> And my 2c worth on the "lvm unmounting filesystems on error" - stop
> it, now. It's the wrong thing to do, and it makes it impossible for
> filesystems to handle the error and recover gracefully when
> possible.
It's causing way more
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.
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
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
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, 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
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
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 file system behind the users back is activ
Dne 16.12.2016 v 09:15 Christoph Hellwig napsal(a):
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 file system behind the users back is actively
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 file system behind the users back is actively harmful, as it is
contradicting the principle of leas
Dne 15.12.2016 v 09:42 Christoph Hellwig napsal(a):
On Thu, Dec 15, 2016 at 05:36:50PM +1100, Dave Chinner wrote:
Yup, same here. My local patch is this:
I have a sleep 1 before the unmount. To be honest this lvm behavior of
auto-unmounting on error seems like a huge mess, I wonder if there i
On Thu, Dec 15, 2016 at 05:36:50PM +1100, Dave Chinner wrote:
> Yup, same here. My local patch is this:
I have a sleep 1 before the unmount. To be honest this lvm behavior
of auto-unmounting on error seems like a huge mess, I wonder if there is
a way to disable it?
Even on a production system I'
24 matches
Mail list logo
