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

[David Wright]

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.

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

[Henrique de Moraes Holschuh]

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

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

[Jonathan Dowland]

On Fri, Jul 28, 2017 at 04:27:32PM +0200, Dan wrote:

Hi,

I have a NFS4 server with ext4. I'm moving to Debian Stretch. I wonder if I
should switch to Btrfs.

I like the checksum feature to prevent silent corruption.


Lacking this feature in the filesystems I use for data storage (ext4 and
XFS), my plan was to set up an alert for my backup system, such that I
will be notified if a particular incremental backup is larger than
expected (suggesting more files changed than expected).

At a finer level of detail, I wish to write rules so e.g. "files under
path /foo are not expected to change".

But I haven't produced this yet.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

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

[David Wright]

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.

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

[rhkramer]

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 +
> > > Andy Smith  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.

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

[Zenaan Harkness]

On Sat, Aug 12, 2017 at 03:03:38AM +, 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 +
> > > Andy Smith  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,

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

[Andy Smith]

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 +
> > Andy Smith  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

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

[Christian Seiler]

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

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

[Dejan Jocic]

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 +
> > > > > Andy Smith  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 < [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.

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

[Christian Seiler]

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 +
> > Andy Smith  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 <
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

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

[Gary Dale]

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 +
Andy Smith  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?

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

[Dan Ritter]

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 +
> > > Andy Smith  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-

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

[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 +
> > > Andy Smith  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.

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

[David Wright]

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 +
> > Andy Smith  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.

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

[Dan Ritter]

On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> On Sat, 29 Jul 2017 04:59:40 +
> Andy Smith  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-

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

[David Niklas]

On Sat, 29 Jul 2017 04:59:40 +
Andy Smith  wrote:

> > 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

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

[Dan]

Dear Andy,

Thanks a lot for your answer.

On Sat, Jul 29, 2017 at 6:59 AM, Andy Smith  wrote:
> Hello,
>
> On Fri, Jul 28, 2017 at 04:27:32PM +0200, Dan wrote:
>> I have a NFS4 server with ext4. I'm moving to Debian Stretch. I wonder if I
>> should switch to Btrfs.
>
> I personally wouldn't. I do use btrfs at home and wish I didn't,
> will be moving away from it soon.
>

I'll follow your advice and continue using ext4. Too bad that btfrs is
still not ready. Looking forward to the time when Btrfs will be ready
for production.

>
> You could consider ZFS on Linux.
>
> http://zfsonlinux.org/
>

I prefer to use something that is in the "official" linux kernel tree.
Too bad there are these licence issues (CDDL vs GPL)

>> 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?
> Having RAID and scrubbing it regularly helps. It will at least spot
> mismatches. The mdadm package on Debian does that by default once
> per month and I could recommend making that more often if it doesn't
> cause you performance issues. Also note that if you only have a two
> way mirror and you find out there are mismatches, you may not be
> able to tell which mirror has the correct data. Forcing md to fix it
> will cause it to pick one side at random.

I'll take a look into the mdadm package and will consider RAID.

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

Hope that some day Oracle will free the license of ZFS and let the
Linux community use it under the GPL terms.

Best,
Daniel

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

[Andy Smith]

Hello,

On Fri, Jul 28, 2017 at 04:27:32PM +0200, Dan wrote:
> I have a NFS4 server with ext4. I'm moving to Debian Stretch. I wonder if I
> should switch to Btrfs.

I personally wouldn't. I do use btrfs at home and wish I didn't,
will be moving away from it soon.

Take a look at the archives of the linux-btrfs list and note how
many threads there still are involving phantom -ENOSPC issues,
problems where filesystems cannot be mounted unless kernel and
tools are updated to bleeding edge versions, and occasionally
outright data loss.

I haven't had data loss but I've had the -ENOSPC problems and also
situations where a dead device can't be removed and a replacement
added without rebooting and upgrading kernel. These are not things I
expect from a redundant filesystem and so for me it's not ready yet.

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/

> I like the checksum feature to prevent silent corruption.

You could consider ZFS on Linux.

http://zfsonlinux.org/

> 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 do backups very often, I don't mind if the hard drive dies,
> but I don't want silent corruption.

Error-checking filesystem isn't a substitute for backups so you'll
always need those. Make sure you have historical versions so you can
check for silent corruption.

Having RAID and scrubbing it regularly helps. It will at least spot
mismatches. The mdadm package on Debian does that by default once
per month and I could recommend making that more often if it doesn't
cause you performance issues. Also note that if you only have a two
way mirror and you find out there are mismatches, you may not be
able to tell which mirror has the correct data. Forcing md to fix it
will cause it to pick one side at random.

I'm sure there will be plenty of people who have used btrfs for
years and had no issue. But I didn't do anything wrong with it, did
have issues, and so do a lot of other posters to linux-btrfs.
Nothing is perfect but the amount of problems I still see there is
enough cause for concern to me.

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

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Btrs vs ext4. Which one is more reliable?

[Dan]

Hi,

I have a NFS4 server with ext4. I'm moving to Debian Stretch. I wonder if I
should switch to Btrfs.

I like the checksum feature to prevent silent corruption.

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? I do backups very often, I don't mind if the hard drive dies,
but I don't want silent corruption.

Suse has been using Btrfs for a while. Can I consider Btrfs in Stretch
stable enough for a NFS4 server? I would use only snapshots and subvolumes.

Thanks,
Daniel