Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #184967 > unrolled thread

Re: Btrs vs ext4. Which one is more reliable?

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Btrs vs ext4. Which one is more reliable? David Niklas <doark@mail.com> - 2017-08-10 06:10 +0200
    Re: Btrs vs ext4. Which one is more reliable? Dan Ritter <dsr@randomstring.org> - 2017-08-10 13:10 +0200
      Re: Btrs vs ext4. Which one is more reliable? David Wright <deblis@lionunicorn.co.uk> - 2017-08-10 15:50 +0200
        Re: Btrs vs ext4. Which one is more reliable? Dan Ritter <dsr@randomstring.org> - 2017-08-10 16:10 +0200
        Re: Btrs vs ext4. Which one is more reliable? Dejan Jocic <jodejka@gmail.com> - 2017-08-10 16:10 +0200
          Re: Btrs vs ext4. Which one is more reliable? Christian Seiler <christian@iwakd.de> - 2017-08-11 18:00 +0200
            Re: Btrs vs ext4. Which one is more reliable? Dejan Jocic <jodejka@gmail.com> - 2017-08-11 18:30 +0200
              Re: Btrs vs ext4. Which one is more reliable? Christian Seiler <christian@iwakd.de> - 2017-08-11 19:20 +0200
                Re: Btrs vs ext4. Which one is more reliable? David Wright <deblis@lionunicorn.co.uk> - 2017-09-01 03:50 +0200
                  Re: Btrs vs ext4. Which one is more reliable? Henrique de Moraes Holschuh <hmh@debian.org> - 2017-09-01 13:40 +0200
                    Re: Btrs vs ext4. Which one is more reliable? David Wright <deblis@lionunicorn.co.uk> - 2017-09-01 18:00 +0200
        Re: Btrs vs ext4. Which one is more reliable? Gary Dale <garydale@torfree.net> - 2017-08-11 17:00 +0200
      Re: Btrs vs ext4. Which one is more reliable? Andy Smith <andy@strugglers.net> - 2017-08-12 05:10 +0200
        Re: Btrs vs ext4. Which one is more reliable? Zenaan Harkness <zenaan@freedbms.net> - 2017-08-12 09:00 +0200
        Re: Btrs vs ext4. Which one is more reliable? rhkramer@gmail.com - 2017-08-12 15:20 +0200

#184967 — Re: Btrs vs ext4. Which one is more reliable?

On Sat, 29 Jul 2017 04:59:40 +0000
Andy Smith <andy@strugglers.net> wrote:
<snip>
> > My understanding is that the only thing that prevents silent
> > corruption in ext4 is the hard drive CRC (Cyclic Redundancy Check
> > Error). Is that enough for a server?  
> 
> No, not with multi-terabyte devices. CRC doesn't detect well enough,
> also errors can happen at different places that CRC can't always
> detect.

I use RAID5 and reiserfs the only problem I've had so far is RAM
corruption (Ugh!). reierfs is very reliable, does not loose data in the
presence of being unmounted unsuccessfully, WHICH XFS DOES REALLY
BADLY(I think I even saw a video in which an fs dev said that xfs does
this on purpose so that an sensitive data does not remain on the drive).
I also tried fat32, but in the presence of being unmounted incorrectly
you'll get some data loss, but not corruption, that is to say that fat32
seems to behave like an atomic fs; either the data is on the drive or not.
Same with ext4 except that I have gotten many corruptions if it's not
properly unmounted. Nilfs2 seems to have a bug someplace in the kernel
(4.9), but I've not yet narrowed it down. I don't know anything about
others then those listed above.

Yes, I've been really busy trying to find a good FS.

> The worst I've seen on the zfsonlinux list in the last couple of
> years is people reporting abnormally low performance in their
> configuration.
> 
> Cheers,
> Andy
> 

Actually, I've read that zfs can only mount on a *totally* empty
directory.


Also, my use case is at home where the power can and *does* fail. I also
find myself using the latest kernel and oftentimes an experimental driver
for my AMD graphics card, hence my need for a *very* stable fs over
sudden unmount.


Sincerely,
David

[toc] | [next] | [standalone]

#184984

On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> On Sat, 29 Jul 2017 04:59:40 +0000
> Andy Smith <andy@strugglers.net> wrote:
> 
> Also, my use case is at home where the power can and *does* fail. I also
> find myself using the latest kernel and oftentimes an experimental driver
> for my AMD graphics card, hence my need for a *very* stable fs over
> sudden unmount.

Buy a cheap UPS with a USB or serial connection to your
computer. Even if it only supplies power for 2 minutes, that's
enough time for the computer to receive the power outage signal
and do an orderly shutdown.

Useful packages:

apcupsd
nut

Cyberpower's UPS systems have Linux support but not Debian
packages; it takes about 10 minutes to download their scripts
and figure out configuration.

-dsr-

[toc] | [prev] | [next] | [standalone]

#184989

On Thu 10 Aug 2017 at 07:04:09 (-0400), Dan Ritter wrote:
> On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > On Sat, 29 Jul 2017 04:59:40 +0000
> > Andy Smith <andy@strugglers.net> wrote:
> > 
> > Also, my use case is at home where the power can and *does* fail. I also
> > find myself using the latest kernel and oftentimes an experimental driver
> > for my AMD graphics card, hence my need for a *very* stable fs over
> > sudden unmount.
> 
> Buy a cheap UPS with a USB or serial connection to your
> computer. Even if it only supplies power for 2 minutes, that's
> enough time for the computer to receive the power outage signal
> and do an orderly shutdown.

Two minutes barely covers the timeouts that can often occur when
shutting down systemd; the commonest timeout period here seems
to be 90 seconds. I wouldn't mind reducing them if that's possible.
Processes got just a few seconds with sysvinit before they were
killed.

> Useful packages:
> 
> apcupsd
> nut
> 
> Cyberpower's UPS systems have Linux support but not Debian
> packages; it takes about 10 minutes to download their scripts
> and figure out configuration.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#184991

On Thu, Aug 10, 2017 at 08:44:33AM -0500, David Wright wrote:
> On Thu 10 Aug 2017 at 07:04:09 (-0400), Dan Ritter wrote:
> > On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > > On Sat, 29 Jul 2017 04:59:40 +0000
> > > Andy Smith <andy@strugglers.net> wrote:
> > > 
> > > Also, my use case is at home where the power can and *does* fail. I also
> > > find myself using the latest kernel and oftentimes an experimental driver
> > > for my AMD graphics card, hence my need for a *very* stable fs over
> > > sudden unmount.
> > 
> > Buy a cheap UPS with a USB or serial connection to your
> > computer. Even if it only supplies power for 2 minutes, that's
> > enough time for the computer to receive the power outage signal
> > and do an orderly shutdown.
> 
> Two minutes barely covers the timeouts that can often occur when
> shutting down systemd; the commonest timeout period here seems
> to be 90 seconds. I wouldn't mind reducing them if that's possible.
> Processes got just a few seconds with sysvinit before they were
> killed.

I wouldn't know; I only run systemd on throwaway test systems.

I assure you that my Debian, stretch, sysvinit firewall can shutdown
and reboot to full networking in less than 30 seconds. There's nothing
exciting going on in the hardware -- AMD Kabini (low cost, low energy,
low performance) CPU and a small cheap SSD.

30 seconds is an important target, because it's a default
timeout for lots of protocols. 

-dsr-

[toc] | [prev] | [next] | [standalone]

#184992

On 10-08-17, David Wright wrote:
> On Thu 10 Aug 2017 at 07:04:09 (-0400), Dan Ritter wrote:
> > On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > > On Sat, 29 Jul 2017 04:59:40 +0000
> > > Andy Smith <andy@strugglers.net> wrote:
> > > 
> > > Also, my use case is at home where the power can and *does* fail. I also
> > > find myself using the latest kernel and oftentimes an experimental driver
> > > for my AMD graphics card, hence my need for a *very* stable fs over
> > > sudden unmount.
> > 
> > Buy a cheap UPS with a USB or serial connection to your
> > computer. Even if it only supplies power for 2 minutes, that's
> > enough time for the computer to receive the power outage signal
> > and do an orderly shutdown.
> 
> Two minutes barely covers the timeouts that can often occur when
> shutting down systemd; the commonest timeout period here seems
> to be 90 seconds. I wouldn't mind reducing them if that's possible.
> Processes got just a few seconds with sysvinit before they were
> killed.
> 

Yes, those 90 sec waiting for nothing is one of the most annoying
"features" of systemd that I would love to get rid of. And most annoying
aspect of it is that problem is rarely constant. It can exist in one
release in systemd, vanish in other, and then come back again in next
release. And it can occur once in every 10 shutdowns/reboots, or not
occur once in every 10 shutdowns/reboots.

[toc] | [prev] | [next] | [standalone]

#185049

Am 2017-08-10 16:02, schrieb Dejan Jocic:
> On 10-08-17, David Wright wrote:
>> On Thu 10 Aug 2017 at 07:04:09 (-0400), Dan Ritter wrote:
>> > On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
>> > > On Sat, 29 Jul 2017 04:59:40 +0000
>> > > Andy Smith <andy@strugglers.net> wrote:
>> > >
>> > > Also, my use case is at home where the power can and *does* fail. I also
>> > > find myself using the latest kernel and oftentimes an experimental driver
>> > > for my AMD graphics card, hence my need for a *very* stable fs over
>> > > sudden unmount.
>> >
>> > Buy a cheap UPS with a USB or serial connection to your
>> > computer. Even if it only supplies power for 2 minutes, that's
>> > enough time for the computer to receive the power outage signal
>> > and do an orderly shutdown.
>> 
>> Two minutes barely covers the timeouts that can often occur when
>> shutting down systemd; the commonest timeout period here seems
>> to be 90 seconds. I wouldn't mind reducing them if that's possible.
>> Processes got just a few seconds with sysvinit before they were
>> killed.
>> 
> 
> Yes, those 90 sec waiting for nothing is one of the most annoying
> "features" of systemd that I would love to get rid of.

You can set TimeoutStopSec= for some units explicitly, for example
via drop-in. Example:

mkdir -p /etc/systemd/system/XYZ.service.d
cat > /etc/systemd/system/XYZ.service.d/stop-timeout.conf <<EOF
[Service]
TimeoutStopSec=10s
EOF

Even if the service is only provided by an init script this will
still work.

You can also set DefaultTimeoutStopSec= in /etc/systemd/system.conf
to alter the default for all units (though individual settings for
units will still override that).

> And most annoying
> aspect of it is that problem is rarely constant. It can exist in one
> release in systemd, vanish in other, and then come back again in next
> release. And it can occur once in every 10 shutdowns/reboots, or not
> occur once in every 10 shutdowns/reboots.

That is an indication that you have a race condition during
shutdown.

The "90s" thing is basically just systemd saying: yeah, I've tried
to shutdown a specific unit and it's still active, now I'm going
to wait for the timeout before I send a hard SIGKILL. You can't
really compare that to sysvinit, because sysvinit doesn't actually
track processes properly, so what most often would happen is that
the init script would send a TERM signal to a process, the better
ones maybe also a KILL signal after some time, before they'd just
consider the service stopped. But if other processes had been
started by the service, sysvinit wouldn't care about them, and
only kill those in the final "let's kill all that's still left
over" killing spree. systemd by contrast actually tracks what's
happening with a service and kills the remaining processes.

That said: what could happen here is that the systemd unit created
for a given service has a bug. For example it could not be ordered
correctly and hence systemd tries to stop it too early while other
services still depend on it.

Or the stop command that is called by systemd hangs because it
tries to do something that it shouldn't do during shutdown (for
example start another service).

See the following page for information on how to debug shutdown
issues with systemd (and keep in mind that Debian has systemd stuff
installed  in /lib and not /usr/lib):
https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

I've found systemd to be far more reliable during shutdown (even
if you have to wait for a timeout if something's gone wrong),
because at least there is a timeout. With sysvinit I've sometimes
had the problem that a shutdown script would hang and then nothing
further would happen and the computer would never properly shut
down. This was especially frustrating with headless machines. What
systemd does do is make it much more apparent if there's a
misconfiguration somewhere.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#185050

On 11-08-17, Christian Seiler wrote:
> Am 2017-08-10 16:02, schrieb Dejan Jocic:
> > On 10-08-17, David Wright wrote:
> > > On Thu 10 Aug 2017 at 07:04:09 (-0400), Dan Ritter wrote:
> > > > On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > > > > On Sat, 29 Jul 2017 04:59:40 +0000
> > > > > Andy Smith <andy@strugglers.net> wrote:
> > > > >
> > > > > Also, my use case is at home where the power can and *does* fail. I also
> > > > > find myself using the latest kernel and oftentimes an experimental driver
> > > > > for my AMD graphics card, hence my need for a *very* stable fs over
> > > > > sudden unmount.
> > > >
> > > > Buy a cheap UPS with a USB or serial connection to your
> > > > computer. Even if it only supplies power for 2 minutes, that's
> > > > enough time for the computer to receive the power outage signal
> > > > and do an orderly shutdown.
> > > 
> > > Two minutes barely covers the timeouts that can often occur when
> > > shutting down systemd; the commonest timeout period here seems
> > > to be 90 seconds. I wouldn't mind reducing them if that's possible.
> > > Processes got just a few seconds with sysvinit before they were
> > > killed.
> > > 
> > 
> > Yes, those 90 sec waiting for nothing is one of the most annoying
> > "features" of systemd that I would love to get rid of.
> 
> You can set TimeoutStopSec= for some units explicitly, for example
> via drop-in. Example:
> 
> mkdir -p /etc/systemd/system/XYZ.service.d
> cat > /etc/systemd/system/XYZ.service.d/stop-timeout.conf <<EOF
> [Service]
> TimeoutStopSec=10s
> EOF
> 
> Even if the service is only provided by an init script this will
> still work.
> 
> You can also set DefaultTimeoutStopSec= in /etc/systemd/system.conf
> to alter the default for all units (though individual settings for
> units will still override that).
> 

Thank you for suggestion. I did find that solution, some time ago, can't
remember exactly where. But it was followed by warning that it is bad
idea, can't remember exactly why. Do you have any hint of why it could
be bad idea to limit timeout, or I've just misunderstood whatever I've
read about it?

> > And most annoying
> > aspect of it is that problem is rarely constant. It can exist in one
> > release in systemd, vanish in other, and then come back again in next
> > release. And it can occur once in every 10 shutdowns/reboots, or not
> > occur once in every 10 shutdowns/reboots.
> 
> That is an indication that you have a race condition during
> shutdown.
> 
> The "90s" thing is basically just systemd saying: yeah, I've tried
> to shutdown a specific unit and it's still active, now I'm going
> to wait for the timeout before I send a hard SIGKILL. You can't
> really compare that to sysvinit, because sysvinit doesn't actually
> track processes properly, so what most often would happen is that
> the init script would send a TERM signal to a process, the better
> ones maybe also a KILL signal after some time, before they'd just
> consider the service stopped. But if other processes had been
> started by the service, sysvinit wouldn't care about them, and
> only kill those in the final "let's kill all that's still left
> over" killing spree. systemd by contrast actually tracks what's
> happening with a service and kills the remaining processes.
> 
> That said: what could happen here is that the systemd unit created
> for a given service has a bug. For example it could not be ordered
> correctly and hence systemd tries to stop it too early while other
> services still depend on it.
> 
> Or the stop command that is called by systemd hangs because it
> tries to do something that it shouldn't do during shutdown (for
> example start another service).
> 
> See the following page for information on how to debug shutdown
> issues with systemd (and keep in mind that Debian has systemd stuff
> installed  in /lib and not /usr/lib):
> https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
> 
> I've found systemd to be far more reliable during shutdown (even
> if you have to wait for a timeout if something's gone wrong),
> because at least there is a timeout. With sysvinit I've sometimes
> had the problem that a shutdown script would hang and then nothing
> further would happen and the computer would never properly shut
> down. This was especially frustrating with headless machines. What
> systemd does do is make it much more apparent if there's a
> misconfiguration somewhere.
> 
> Regards,
> Christian
> 

Thank you for your explanation. I do understand why it is happening, did
some reading about that subject even before I've ran on that bug, but it
is still annoying. As for more reliable during shutdown part, not in
my experience, at least on Stretch. It was on Jessie though, where that
feature was hitting me not more than once in every 15-20
shutdowns/reboots. 


Anyway, thank you for your time and help.

[toc] | [prev] | [next] | [standalone]

#185053

Hi there,

On 08/11/2017 06:29 PM, Dejan Jocic wrote:
> On 11-08-17, Christian Seiler wrote:
>> You can also set DefaultTimeoutStopSec= in /etc/systemd/system.conf
>> to alter the default for all units (though individual settings for
>> units will still override that).
>>
> Thank you for suggestion. I did find that solution, some time ago, can't
> remember exactly where. But it was followed by warning that it is bad
> idea, can't remember exactly why. Do you have any hint of why it could
> be bad idea to limit timeout, or I've just misunderstood whatever I've
> read about it?

Well, there's a reason the default is 90s. And for some services even
that might be too short. Take for example a database server where the
regular stop script might take 10 minutes to shut down properly (when
no error occurs).

On the other hand for other services you can easily get away with a
lot less of a timeout. For example, I have apt-cache-ng running on
my system (to cache stuff for sbuild), and I think it's perfectly
reasonable to set the stop timeout for that service to 10s or even
lower because that's just a stupid proxy. On the other hand I've
never experienced apt-cacher-ng to take longer than 1s or so to stop,
so I haven't bothered.

The right timeout is always a balancing act - and systemd's default
is a compromise to provide something that won't break most use cases
but still cause the system to shut down after a finite time.

It's up to you to decide what the best option here is. I wouldn't
set the default to anything lower than 30s myself, but that's just
a gut feeling, and I don't actually have any hard data to back that
number up.

> As for more reliable during shutdown part, not in
> my experience, at least on Stretch.

I don't recall ever running into the timeout on shutdown since Stretch
has been released as stable. And I am running a couple of Strech
systems myself, both at home and at work.

> It was on Jessie though, where that
> feature was hitting me not more than once in every 15-20
> shutdowns/reboots. 

Even every 15-20 shutdowns is too much. I never experience those
unless something's wrong. And then I debug hat problem to see what
is causing it and get rid of the root problem so that it doesn't
occur again.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#186262

On Fri 11 Aug 2017 at 19:13:47 (+0200), Christian Seiler wrote:
> Hi there,
> 
> On 08/11/2017 06:29 PM, Dejan Jocic wrote:
> > On 11-08-17, Christian Seiler wrote:
> >> You can also set DefaultTimeoutStopSec= in /etc/systemd/system.conf
> >> to alter the default for all units (though individual settings for
> >> units will still override that).

That works great. I've set   DefaultTimeoutStopSec=27s

> > Thank you for suggestion. I did find that solution, some time ago, can't
> > remember exactly where. But it was followed by warning that it is bad
> > idea, can't remember exactly why. Do you have any hint of why it could
> > be bad idea to limit timeout, or I've just misunderstood whatever I've
> > read about it?
> 
> Well, there's a reason the default is 90s. And for some services even
> that might be too short. Take for example a database server where the
> regular stop script might take 10 minutes to shut down properly (when
> no error occurs).

The problem only embarrasses me on laptops, eg leaving the house,
boarding an aircraft, etc. Nothing important is running (I've already
killed X and touched the power button) and the only alternative is
forcing it off with the prolonged power button.

It's worked well for a fortnight now.

> The right timeout is always a balancing act - and systemd's default
> is a compromise to provide something that won't break most use cases
> but still cause the system to shut down after a finite time.

There are some timeouts that are set to "no limit" but I haven't hit
one of those for nearly a year. It's incomprehensible to me why
"RPC portmapper replacement" needs to be shut down cleanly however
long it takes. Likewise the "Color Profiles" manager which, while
having a 90 second timeout to start with, would increment the timeout
by another 90 seconds each time it expired, so it was effectively
infinite.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#186276

On Thu, 31 Aug 2017, David Wright wrote:
> "RPC portmapper replacement" needs to be shut down cleanly however
> long it takes. Likewise the "Color Profiles" manager which, while

Because if it didn't exit, it most likely means an NFS partition is
still unmounting and you could incur data loss if killing RPC causes
that NFS partition to "hang".

> having a 90 second timeout to start with, would increment the timeout
> by another 90 seconds each time it expired, so it was effectively
> infinite.

Now, that's just your usual bug, I think.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#186280

On Fri 01 Sep 2017 at 08:34:25 (-0300), Henrique de Moraes Holschuh wrote:
> On Thu, 31 Aug 2017, David Wright wrote:
> > "RPC portmapper replacement" needs to be shut down cleanly however
> > long it takes. Likewise the "Color Profiles" manager which, while
> 
> Because if it didn't exit, it most likely means an NFS partition is
> still unmounting and you could incur data loss if killing RPC causes
> that NFS partition to "hang".

I don't know why systemd would think that I had NFS partitions.
I haven't run a server since 2004, and have never used a linux
NFS client, only DOS6.22 ones.

> > having a 90 second timeout to start with, would increment the timeout
> > by another 90 seconds each time it expired, so it was effectively
> > infinite.
> 
> Now, that's just your usual bug, I think.

I couldn't find any mention of timeouts increasing on their own,
either in BTS under systemd or googling. Even now, I only see
wishlists for making such timeouts interruptible with ^C.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#185046

On 10/08/17 09:44 AM, David Wright wrote:
> On Thu 10 Aug 2017 at 07:04:09 (-0400), Dan Ritter wrote:
>> On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
>>> On Sat, 29 Jul 2017 04:59:40 +0000
>>> Andy Smith <andy@strugglers.net> wrote:
>>>
>>> Also, my use case is at home where the power can and *does* fail. I also
>>> find myself using the latest kernel and oftentimes an experimental driver
>>> for my AMD graphics card, hence my need for a *very* stable fs over
>>> sudden unmount.
>> Buy a cheap UPS with a USB or serial connection to your
>> computer. Even if it only supplies power for 2 minutes, that's
>> enough time for the computer to receive the power outage signal
>> and do an orderly shutdown.
> Two minutes barely covers the timeouts that can often occur when
> shutting down systemd; the commonest timeout period here seems
> to be 90 seconds. I wouldn't mind reducing them if that's possible.
> Processes got just a few seconds with sysvinit before they were
> killed.
>

> Still it is sufficient to do an orderly shutdown when power is lost 
> and your network hardware might be off.
The bigger issue is why would anyone use experimental drivers and the 
latest kernel when they are worried about reliability?

[toc] | [prev] | [next] | [standalone]

#185078

Hello,

On Thu, Aug 10, 2017 at 07:04:09AM -0400, Dan Ritter wrote:
> On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > On Sat, 29 Jul 2017 04:59:40 +0000
> > Andy Smith <andy@strugglers.net> wrote:
> > 
> > Also, my use case is at home where the power can and *does* fail. I also
> > find myself using the latest kernel and oftentimes an experimental driver
> > for my AMD graphics card, hence my need for a *very* stable fs over
> > sudden unmount.

Dan's broken quoting implies that I wrote the above, but I didn't.

Cheers,
Andy

[toc] | [prev] | [next] | [standalone]

#185085

On Sat, Aug 12, 2017 at 03:03:38AM +0000, Andy Smith wrote:
> Hello,
> 
> On Thu, Aug 10, 2017 at 07:04:09AM -0400, Dan Ritter wrote:
> > On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > > On Sat, 29 Jul 2017 04:59:40 +0000
> > > Andy Smith <andy@strugglers.net> wrote:
> > > 
> > > Also, my use case is at home where the power can and *does* fail. I also
> > > find myself using the latest kernel and oftentimes an experimental driver
> > > for my AMD graphics card, hence my need for a *very* stable fs over
> > > sudden unmount.
> 
> Dan's broken quoting implies that I wrote the above, but I didn't.

Ah yes, this reminds me of a thought of "maximizing rationality
whilst minimizing effort" which has finally percolated to the top of
my two brain cells:

When someone misquotes me, when is it useful or relevant to correct
the record?

A) When the misattributed quote could have an adverse consequence
on my internal life:
   - When I have an attachment to never being misattributed (bin
     there)?
   - perhaps I was involved in, or witnessed some less than wholesome
     rhetoric arising from misattribution, and want to protect myself
     from such possibility?
   - etc

B) When the misattributed quote could have an adverse consequence on
my external life:
   - Perhaps the quote could affect a potential employer/HR person
     assessing me as a candidate for a job?
   - The misattribution could be held against me in personal
     relationships?
   - Where I get credit for someone else's "positive" (yet still
     misattributed) quote - I experienced this once many years ago.
   - or perhaps other hypotheticals...


On these basis ("basii"? "bases"?) I have concluded for myself that
most misattribution has a lower overall/ personal energy cost, when I
ignore the misattribution. The only exception I make these days is
when others might give credit for something someone else actually
deserves the credit for. In all other situations, e.g. a potential
employer interviewer asking "so why the blip did you say this?!" -
would actually be to my long term favour ("welll... if you just look
a little closer, you might find I actually did not say that...").

Have a good one all,

[toc] | [prev] | [next] | [standalone]

#185093

On Friday, August 11, 2017 11:03:38 PM Andy Smith wrote:
> Hello,
> 
> On Thu, Aug 10, 2017 at 07:04:09AM -0400, Dan Ritter wrote:
> > On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > > On Sat, 29 Jul 2017 04:59:40 +0000
> > > Andy Smith <andy@strugglers.net> wrote:
> > > 
> > > Also, my use case is at home where the power can and *does* fail. I
> > > also find myself using the latest kernel and oftentimes an
> > > experimental driver for my AMD graphics card, hence my need for a
> > > *very* stable fs over sudden unmount.
> 
> Dan's broken quoting implies that I wrote the above, but I didn't.

The quoting might be broken (I'm not sure about that, and didn't go back to 
look), but, as I read it, it tells me that text was written by David Niklas.  
I think maybe other text written by you was just omitted, making it a little 
harder to interpret.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web