Re: [DNG] Request file system reviews and recomendations.

[J. Fahrner]

Am 2017-12-29 21:35, schrieb Adam Borowski:

resize2fs -b $DEV
tune2fs -O metadata_csum $DEV
fsck.ext4 -D $DEV


According to this wiki:
https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

should we also use option journal_checksum on mount?

Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Adam Borowski (kilob...@angband.pl):

[enabling metadata checksums on relatively old ext4 filesystems:]

> Thus, if you created your filesystem with mkfs.ext4 older than
> stretch/ascii, it's vital that you do the following, on an unmounted
> filesystem (ie, need to boot from alternate media if it's /):
> 
> resize2fs -b $DEV
> tune2fs -O metadata_csum $DEV
> fsck.ext4 -D $DEV

First, thank you.  We're all richer for this sharing of knowledge.

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout clarifies what
this specific command sequence is about: the '64bit' feature and its
connection to block size and to the metadata checksum option:

  By default a filesystem can contain 2^32 blocks; if the '64bit'
  feature is enabled, then a filesystem can have 2^64 blocks.
  [...]

  Some [hisorical ext4] data structures did not have space to fit a full
  32-bit checksum, so only the lower 16 bits are stored. Enabling the
  64bit feature increases the data structure size so that full 32-bit
  checksums can be stored for many data structures. However, existing
  32-bit filesystems cannot be extended to enable 64bit mode, at least not
  without the experimental resize2fs patches to do so.

One gathers that the 'experimental resize2fs patches' have been merged
since the above was written.

  Existing filesystems can have checksumming added by running tune2fs -O
  metadata_csum against the underlying device.
  [...]

So, 'resize2fs -b [devicename]' turns on the filesystem's 64bit feature,
rewriting ext4 metadata in a way that makes adequate room for storing
full 32-bit checksums on all file metadata structures instead of just
the lower 16 bits -- with the minor drawback of making the ext4
filsystem unmountable by systems with pre-3.6 kernels.  Having done this
house-cleaning, now you can do the second command that toggles on the
metadata checksum option.  Last, 'fsck.ext4 -D [devicename' 'optimises'
(reindexes, or sorts and compresses) all directories.

-- 
Cheers,  "Like running into a burning building and trying to put the
Rick Moen fire out by means of interpretive dance." -- Iain M. Banks
r...@linuxmafia.com   on alternative cancer treatments, after his own diagnosis
McQ! (4x80) www.theguardian.com/books/2013/jun/15/iain-banks-the-final-interview
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Adam Borowski]

On Thu, Dec 28, 2017 at 08:41:13PM -0500, Steve Litt wrote:
> On Fri, 29 Dec 2017 01:15:10 +0100
> Harald Arnesen  wrote:
> 
> > I see what you mean, and I have never had a problem with ext4 either.
> > But I have used btrfs on all my main machines for the last years, and
> > have not had any (filesystem) problems with them either. I'd like to
> > see empirical evidence that ext4 is so much more stable than btrfs.
> 
> I can't give you empirical evidence. It's a guess on my part.

Here's one: when ext4 is running on flaky hardware, it gives hard to
diagnose errors that at the first glance don't look like disk corruption at
all: mostly, you get random segfaults.  Btrfs on the other hand immediately
informs you what's wrong.

Failure mode on this relatively frequent problem is quite nasty.

But, not all is lost.  ext4 has recently grown metadata (only) checksums,
and having them protects you from worst kinds of corruption.  As is, data
corruption is localized, metadata breakage can kill the whole filesystem.
You also get a random chance to be notified of problems with disk cable/
controller/etc, as a bad write or read will hit a metadata block sooner or
later.

Thus, if you created your filesystem with mkfs.ext4 older than
stretch/ascii, it's vital that you do the following, on an unmounted
filesystem (ie, need to boot from alternate media if it's /):

resize2fs -b $DEV
tune2fs -O metadata_csum $DEV
fsck.ext4 -D $DEV

There's a caveat that such a filesystem can't be mounted with kernels prior
to 3.6 (I found this the hard way, after mkfs-ing on unstable), but by now,
this shouldn't be a concern as even jessie has 3.16.


Unrelated: while you're at it, give tytso a big thumbs-up for the third
paragraph of "man resize2fs".  These wise words deserve a beer donation.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Andrew McGlashan]

On 29/12/17 13:57, Rick Moen wrote:
> One can also reasonably say that the ext2/ext3/ext4 codebase has
> benefited from more real-world testing than any other *ix fileystem code
> in history.  (ext4 departs significantly more from ext3 than the latter
> did from ext2, as detailed here:
> https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem )

Okay, that lead me to consider TRIM for my SSD... everything I need is
covered just fine, but the following blog post might be useful to some:

http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

On my Linux Mint 18.3 laptop, I already had discard in /etc/crypttab (I
never put it there).

It was also already enabled in my /etc/lvm/lvm.conf file as well, (again
I didn't put it there).

And a very simple weekly job (compliments of Mint team I guess) also
takes care of fstrim for all file-systems that support it as follows:

# cat /etc/cron.weekly/fstrim
#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true


Cheers
AndrewM



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Hendrik Boom]

On Thu, Dec 28, 2017 at 08:49:56PM +0100, Adam Borowski wrote:
> On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
> > btrfs is still scarily beta after rather a lot of years of development.

That's what worries me about btrfs.

'''
'''

> As for its state: btrfs is, well, btrfs.  You get both extremely powerful
> data protection features you won't want to live without, and WTF level
> caveats.  I wouldn't recommend using btrfs unless you know where the corpses
> are buried.

I guess it's time to ask, 

  Where are the corpses buried?

If I were to use btrfs, it looks as if I'd have to know this.

-- hendrik

> 
> But if you do, you get:
> 
> * data and metadata checksums.

That's why I'm leaning toward btrfs.

>  It is scary how inadequate disks' own
>   checksums are, and how often firmware bugs, bad cables, motherboard or
>   hostile fairies cause data corruption.  On ext*, this leads to silent data
>   loss that you then discover months later once backups get overwritten.
>   Out of all my bad disks/eMMC/SD since I started looking at this, that were
>   not total device loss, at least some silent corruption happened in _every_
>   _single_ _case_.  You have for example two sectors the controller reported
>   and 3K other sectors it did not.
> 
> * better chances to survive unclean shutdown than non-cow filesystem.  Ext*
>   can be told to provide an equivalent level of protection but then it needs
>   to write every bit of data twice.

Yes.  At the moment I am actually having it write every bit of data 
twice.  And I still get adequate performance.  Maye this shows how 
modest my performance demands are.

...
...

> Other downside is the need for maintenance.  On single dev, you can live
> well without, but on multi dev you need to do manually a lot that's taken
> for granted with MD.

What's needed for maintenance?

-- hendrik

> 
> Another caveat: don't forget to mount with noatime.

I presume that's just a performance issue, not a bug.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Hendrik Boom]

On Thu, Dec 28, 2017 at 11:11:35AM -0500, Steve Litt wrote:
> 
> In other words, I prioritized the extreme amount of user testing of
> ext4 over the obvious convenience of btrfs. My prioritization isn't
> universal: In fact, I'm probably in the minority. But it's worked for
> me.

I'm in the same minority.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> On Fri, 29 Dec 2017 01:15:10 +0100
> Harald Arnesen  wrote:
> 
> > I see what you mean, and I have never had a problem with ext4 either.
> > But I have used btrfs on all my main machines for the last years, and
> > have not had any (filesystem) problems with them either. I'd like to
> > see empirical evidence that ext4 is so much more stable than btrfs.
> 
> I can't give you empirical evidence. It's a guess on my part.

One can also reasonably say that the ext2/ext3/ext4 codebase has
benefited from more real-world testing than any other *ix fileystem code
in history.  (ext4 departs significantly more from ext3 than the latter
did from ext2, as detailed here:
https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem )


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Steve Litt]

On Fri, 29 Dec 2017 01:15:10 +0100
Harald Arnesen  wrote:

> I see what you mean, and I have never had a problem with ext4 either.
> But I have used btrfs on all my main machines for the last years, and
> have not had any (filesystem) problems with them either. I'd like to
> see empirical evidence that ext4 is so much more stable than btrfs.

I can't give you empirical evidence. It's a guess on my part.


SteveT

Steve Litt 
December 2017 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Harald Arnesen]

Den 2017-12-28 17:11, skrev Steve Litt:

> That's exactly my point. To do something better than my backup
> solution, I would have needed to go with something less tested, with
> less complete supporting software, and something I trust less than
> ext4. I haven't had ext4 mess up on me in at least 6 years. Even ext2
> and ext3 messed up very rarely, and you could usually fix them with an
> fsck.

I see what you mean, and I have never had a problem with ext4 either.
But I have used btrfs on all my main machines for the last years, and
have not had any (filesystem) problems with them either. I'd like to see
empirical evidence that ext4 is so much more stable than btrfs.
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Didier Kryn]

Le 28/12/2017 à 20:49, Adam Borowski a écrit :

On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:

btrfs is still scarily beta after rather a lot of years of development.
Its prospects have dimmed further now that Red Hat have dropped it from
their roadmap.

And why would Red Hat matter?  It's similar to as if Apple dropped an iTunes
app for Android.

Red Hat never participated in btrfs development, has its own enterprisey
storage tools it peddles to paying customers that directly compete with
btrfs' features, never bothered to fix systemd's issues with basic btrfs
operation.  Also, on their paid distribution (RHEL not Fedora), they provide
ridiculously ancient kernels they then backport features to.  This is not
going to work for a filesystem of the complexity of btrfs unless you put
enough manpower on fixing issues caused by such backporting: Red Hat never
had as much as a single engineer dedicated to btrfs.  No wonder they don't
want to get involved.

If, say, SuSE or Facebook backed out, _this_ would be a concern.


As for its state: btrfs is, well, btrfs.  You get both extremely powerful
data protection features you won't want to live without, and WTF level
caveats.  I wouldn't recommend using btrfs unless you know where the corpses
are buried.

But if you do, you get:

* data and metadata checksums.  It is scary how inadequate disks' own
   checksums are, and how often firmware bugs, bad cables, motherboard or
   hostile fairies cause data corruption.  On ext*, this leads to silent data
   loss that you then discover months later once backups get overwritten.
   Out of all my bad disks/eMMC/SD since I started looking at this, that were
   not total device loss, at least some silent corruption happened in _every_
   _single_ _case_.  You have for example two sectors the controller reported
   and 3K other sectors it did not.

* better chances to survive unclean shutdown than non-cow filesystem.  Ext*
   can be told to provide an equivalent level of protection but then it needs
   to write every bit of data twice.

* O(changes) backup.  Using rsync, a spinning disk is likely to take half an
   hour just to stat() everything (obviously depends on the number of files).
   Btrfs on the other hand can enumerate writes since a past snapshot, and
   immediately knows what to transfer.  If you wanted a full backup every 15
   minutes, here you go.

* snapshots to protect from human error.  You are a human, so are your
   distro's developers.  If X is broken again, you revert to the last working
   snapshot with a single command.  Awesome when running unstable.

These were data protection features.  You also get compression,
deduplication, reflinks, etc.

There are performance downsides, but for POSIX operations, they're
restricted to fsync() and random writes.  There are also performance
upsides: on a slow medium (SD/eMMC, 100Mbit ethernet NBD, etc) compression
can double performance for well-compressible workloads (such as package
building: sources, .o files and especially debug info compress nicely), and
even without compression, switching git branch is ~4 times faster on a SD
card on btrfs and f2fs compared to ext4.

Other downside is the need for maintenance.  On single dev, you can live
well without, but on multi dev you need to do manually a lot that's taken
for granted with MD.

Another caveat: don't forget to mount with noatime.


    So, many attractive features but a lot of learning and maintenance 
work. Plus bugs. The more powerfull the software the more complex and 
error prone. AFAIR, noatime doesn't imply nodiratime, therefore rather 
specify both.


            Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Joel Roth]

Adam Borowski wrote (excerpted):
> As for its state: btrfs is, well, btrfs.  You get both extremely powerful
> data protection features you won't want to live without, and WTF level
> caveats.  I wouldn't recommend using btrfs unless you know where the corpses
> are buried.
> 
> But if you do, you get: 

> * data and metadata checksums.  
> * better chances to survive unclean shutdown > 
( * faster backup than rsync)
> * snapshots to protect from human error 
 
> You also get compression, deduplication, reflinks, etc.
 
> Other downside is the need for maintenance.  On single dev, you can live
> well without, but on multi dev you need to do manually a lot that's taken
> for granted with MD.
> 
> Another caveat: don't forget to mount with noatime.
 
If someone would like to crowdfund an engineer to work on
this project I would certainly pony up. Even if I don't use
btrfs ATM, I would support to it for the sake of the ecosystem.
 
> 
> Meow!
-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Adam Borowski]

On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
> btrfs is still scarily beta after rather a lot of years of development.
> Its prospects have dimmed further now that Red Hat have dropped it from
> their roadmap.

And why would Red Hat matter?  It's similar to as if Apple dropped an iTunes
app for Android.

Red Hat never participated in btrfs development, has its own enterprisey
storage tools it peddles to paying customers that directly compete with
btrfs' features, never bothered to fix systemd's issues with basic btrfs
operation.  Also, on their paid distribution (RHEL not Fedora), they provide
ridiculously ancient kernels they then backport features to.  This is not
going to work for a filesystem of the complexity of btrfs unless you put
enough manpower on fixing issues caused by such backporting: Red Hat never
had as much as a single engineer dedicated to btrfs.  No wonder they don't
want to get involved.

If, say, SuSE or Facebook backed out, _this_ would be a concern.


As for its state: btrfs is, well, btrfs.  You get both extremely powerful
data protection features you won't want to live without, and WTF level
caveats.  I wouldn't recommend using btrfs unless you know where the corpses
are buried.

But if you do, you get:

* data and metadata checksums.  It is scary how inadequate disks' own
  checksums are, and how often firmware bugs, bad cables, motherboard or
  hostile fairies cause data corruption.  On ext*, this leads to silent data
  loss that you then discover months later once backups get overwritten.
  Out of all my bad disks/eMMC/SD since I started looking at this, that were
  not total device loss, at least some silent corruption happened in _every_
  _single_ _case_.  You have for example two sectors the controller reported
  and 3K other sectors it did not.

* better chances to survive unclean shutdown than non-cow filesystem.  Ext*
  can be told to provide an equivalent level of protection but then it needs
  to write every bit of data twice.

* O(changes) backup.  Using rsync, a spinning disk is likely to take half an
  hour just to stat() everything (obviously depends on the number of files).
  Btrfs on the other hand can enumerate writes since a past snapshot, and
  immediately knows what to transfer.  If you wanted a full backup every 15
  minutes, here you go.

* snapshots to protect from human error.  You are a human, so are your
  distro's developers.  If X is broken again, you revert to the last working
  snapshot with a single command.  Awesome when running unstable.

These were data protection features.  You also get compression,
deduplication, reflinks, etc.

There are performance downsides, but for POSIX operations, they're
restricted to fsync() and random writes.  There are also performance
upsides: on a slow medium (SD/eMMC, 100Mbit ethernet NBD, etc) compression
can double performance for well-compressible workloads (such as package
building: sources, .o files and especially debug info compress nicely), and
even without compression, switching git branch is ~4 times faster on a SD
card on btrfs and f2fs compared to ext4.

Other downside is the need for maintenance.  On single dev, you can live
well without, but on multi dev you need to do manually a lot that's taken
for granted with MD.

Another caveat: don't forget to mount with noatime.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Adam Borowski]

On Thu, Dec 28, 2017 at 12:03:12PM +0100, Didier Kryn wrote:
> Le 27/12/2017 à 01:05, Hendrik Boom a écrit :
> > As I understand it, there are a few new file systems somewhat
> > available on Linux -- ZFS, XFS, and Btrfs.
> 
>     I have tried btrfs; it still runs on a few servers I have installed. I'm
> reluctant to continue with it because it is too tied to RedHat/Systemd

Funny that: I'd strongly recommend not using btrfs and systemd together; it
is also very unfriendly to Red Hat's kernel mess.

Caveats include:

* systemd won't ever mount degraded raid from fstab, as boot device, etc,
  even if you explicitly request -o degraded.

* on manual degraded mounts, systemd will maliciously unmount it!  Your only
  hope is to "mount;cd" and hope to win the race (you'll usually do), after
  which systemd's attempt to unmount will fail.

* long-running processes such as scrub will get killed when you log out the
  session that spawned them (disabled by default on Debian, enabled on Red
  Hat).  Balance survives this (ignores SIGKILL), scrub will finish its
  in-kernel parts then fail to write the result.

> I prefer to use mdadm for RAID - different tools for different tasks.

MD is drastically weaker than btrfs raid:

* it can save you only from errors detected by the disk.  And in case resync
  /check finds a discrepancy, it has no way to repair it: it doesn't know
  which copy is the good one.

* it can do only two equal-sized disks (or three or more, but you won't get
  extra capacity).  Btrfs can take any number of disks of unequal sizes, and
  will fully utilize the capacity unless one disk is bigger than the sum of
  the rest.

>  I partially agree whith what has been said about RAID: it is
> essentially meant to ensure high availability. It doesn't provides all we
> expect from  backup: it does not protect against human errors or malevolent
> actions; yet it is a protection against the consequences of disk failure.

True.  Raid improves your uptime and protects from short-term errors (no
data loss between last backup and failure), but is no substitute for backup.
For a typical server, you need both.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Dr. Nikolaus Klepp (dr.kl...@gmx.at):

> Am Donnerstag, 28. Dezember 2017 schrieb Rick Moen:
> > Quoting Harald Arnesen (har...@skogtun.org):
> 
> > My one-time colleague Ted T'so once wrote an excellent piece, that I
> > can't find at the moment, about how ext2/ext3 code had necessarily
> > been written with a defensive attitude, 
> 
> Could you please post the paper when you find it?

Found it archived (from a mailing list elsewhere) on my own Web server.
;->  (In the archived copy, I elided the mailing list's identity
because it's a private mailing list and I wasn't sure how confidential
it was.  It's not _that_ confidential, so I'll mention that the
discussion was on EVALS, the Ex-VA Linux Systems mailing list for us
former employees.)

'ReiserFS' on http://linuxmafia.com/kb/Filesystems/

Happy New Year / Happy Sylvester, to everyone!

-- 
Cheers,"I am not responsible for the structural integrity 
Rick Moen  of the bubble you've chosen to live in."
r...@linuxmafia.com   -- Mike Norton
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Simon Hobson]

Steve Litt  wrote:

> That's exactly my point. To do something better than my backup
> solution, I would have needed to go with something less tested, with
> less complete supporting software, and something I trust less than
> ext4. I haven't had ext4 mess up on me in at least 6 years. Even ext2
> and ext3 messed up very rarely, and you could usually fix them with an
> fsck.
> 
> In other words, I prioritized the extreme amount of user testing of
> ext4 over the obvious convenience of btrfs. My prioritization isn't
> universal: In fact, I'm probably in the minority. But it's worked for
> me.

Well you aren't alone, some of us still use EXT3 on the basis of "it works" !
Actually, at work a while ago some of the devs were experimenting with running 
Ubuntu with a Windoze VM on top. One had a problem and I found to my surprise 
that the disk that was used to install the system couldn't repair it ! It had 
defaulted to EXT4 for the installed system but didn't have any EXT4 repair 
tools on the disk. IIRC I had to boot it off a recent Debian or Knoppix disk to 
run fsck on it.

I've gone into LVM and MD Raid - the latter having saved me many times from 
failing disks. But EXT3 has served me well and survived many an event - 
accidentally pulling the wrong plug and such like.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Steve Litt]

On Fri, 29 Dec 2017 01:33:43 +1100
Andrew McGlashan  wrote:

> On 28/12/17 15:05, Rick Moen wrote:
> > ECC RAM is not sufficient to catch all bad RAM problems, only some.
> > Back in 2006, I had an interesting case of this:
> > http://linuxmafia.com/pipermail/conspire/2006-December/002662.html
> > http://linuxmafia.com/pipermail/conspire/2006-December/002668.html
> > http://linuxmafia.com/pipermail/conspire/2007-January/002743.html
> > 
> > I know most people won't bother to read that, so I'll summarise:   
> 
> Your posts are almost, if not ALWAYS worth a read!
>   TL/DR; DO BOTHER TO READ RICK'S POSTS
> 
> I recommend it greatly; you are always good value to learn new things
> or new ways to look at things with a different pair of eyes that are
> always attached to a very well functioning brain.
> 
> Your posts are very much appreciated.

Very true.

SteveT

Steve Litt 
December 2017 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Steve Litt]

On Thu, 28 Dec 2017 11:33:13 +0100
Harald Arnesen  wrote:

> Den 28.12.2017 01:51, skrev Steve Litt:
> 
> > The one downfall of my method is if you absolutely, positively need
> > atomic backups: database files, for instance. You'd need to stop
> > work on the computer being backed up. In the case of my Daily Driver
> > Desktop, which contains 3,874,727 files, the entire backup takes
> > about 5 minutes, the last 1.5 minutes of which is the cp -al phase,
> > during which the computer being backed up can go an about its
> > business.  
> 
> Had you used btrfs instead, you could make a snapshot of your file
> system.

Hi Harald,

That's exactly my point. To do something better than my backup
solution, I would have needed to go with something less tested, with
less complete supporting software, and something I trust less than
ext4. I haven't had ext4 mess up on me in at least 6 years. Even ext2
and ext3 messed up very rarely, and you could usually fix them with an
fsck.

In other words, I prioritized the extreme amount of user testing of
ext4 over the obvious convenience of btrfs. My prioritization isn't
universal: In fact, I'm probably in the minority. But it's worked for
me.

SteveT

Steve Litt 
December 2017 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[taii...@gmx.com]

On 12/27/2017 01:34 PM, taii...@gmx.com wrote:

Please remember that all RAID should have ECC RAM and when it comes to 
XFS it is MANDATORY to avoid massive data corruption.

Ahh late night typo for me, correction - ZFS not XFS.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Andrew McGlashan]

On 28/12/17 11:51, Steve Litt wrote:
> Being a fan of simplicity, I use ext4 on all partitions. No LVM: I
> don't want the extra layer. With things like bind mount I can
> temporarily move parts of one filetree to a different partition, and
> the next time I full-install or buy a new computer or something, I can
> resize partitions accordingly.
> 
> ext4 is years old, proven reliable for years, has all the necess
> 
> I don't use disk encryption, but if I did I'd find a way to do it
> without LVM.

LVM is wonderful, the snapshotting with it is excellent for doing
backups and having even less downtime.  I always use ext4 for the
logical volumes and sometimes find that I need to resize the file
systems (resize2fs and other steps).

> I don't use RAID, and to the best of my knowledge I've never had data
> silently go bad on me.

The trouble with bit-rot is that it is silent loss of data; doing extra
checksumming is a potential help for diagnosing lost data though, but
that's why ZFS is so attractive, scrub the file system and it picks up
problems.  Use RAID1 (at least) and ZFS can fix the errant data that it
finds.  Still, the licensing issues and RAM requirements is a bummer, as
is the fact that you really need server class hardware to have any
possibility to use ECC type RAM.

If your 'puter is a portable one, then you really, really should use
full disk encryption.  I've got to admit that the machine I'm replying
on is my portable laptop, it runs stock Linux Mint 18.3 (sadly, with
systemd), it is fully encrypted and boots in a matter of seconds
(longest time is entering the unlock phrase and then my login password
later).  Even non-portable machines can do well to use LUKS (full disk
encryption).

My Devuan KVM machines use dropbear with trusted authorized_keys for
bootup, I unlock the crypted volumes and continue normal boot; the only
issue is that I need to be available to unlock the crypt vols.  But it
does protect the data if the box is lifted or the internal drives are
stolen.

Cheers
A.



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Andrew McGlashan]

On 28/12/17 15:05, Rick Moen wrote:
> ECC RAM is not sufficient to catch all bad RAM problems, only some.
> Back in 2006, I had an interesting case of this:
> http://linuxmafia.com/pipermail/conspire/2006-December/002662.html
> http://linuxmafia.com/pipermail/conspire/2006-December/002668.html
> http://linuxmafia.com/pipermail/conspire/2007-January/002743.html
> 
> I know most people won't bother to read that, so I'll summarise: 

Your posts are almost, if not ALWAYS worth a read!
  TL/DR; DO BOTHER TO READ RICK'S POSTS

I recommend it greatly; you are always good value to learn new things or
new ways to look at things with a different pair of eyes that are always
attached to a very well functioning brain.

Your posts are very much appreciated.

Thank you
AndrewM



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Harald Arnesen]

Den 2017-12-28 12:18, skrev KatolaZ:

> I lost several filesystems with buggy reiserfs versions, back in the
> days, and refused to use it ever again, basically because ext3 had
> become reliable and dependable in the meanwhile. Then Hans Raiser
> stopped its development, for other reasons... 

He stopped development of reiser3 long before what you refer to, and
reiser4 never made it to the kernel, for technical reasons as I recall.
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Arnt Gulbrandsen]

> ext3/ext4 are solid fs, and have
> always been. the lost+found folder is a remainder of the ext2 era, and
> is not even mandatory any more, AFAIU.

lost+found is required since ext3+ext4 permit mounting as ext2, which requires 
it. A poor reason, perhaps, but put differently getting rid of a single 
directory would be a poor reason to remove that little bit of functionality.

Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> I'm reluctant to use ext3/ext4 because I don't understand why they
> still have this strange lost+found directory, which signs a kind of
> weakness.

It's just a receiving area for fragments (inodes without corresponding
filenames) that might in the future be recovered by fsck.  Saying it
indicates a weakness is about as sensible as saying that the presence of
hospitals indicates epidemics.  (FWIW, I've never found anything there
since the arrival of ext3 journaling.)

https://unix.stackexchange.com/questions/18154/what-is-the-purpose-of-the-lostfound-folder-in-linux-and-unix

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[KatolaZ]

On Thu, Dec 28, 2017 at 12:03:12PM +0100, Didier Kryn wrote:
> Le 27/12/2017 à 01:05, Hendrik Boom a écrit :
> >As I understand it, there are a few new file systems somewhat
> >available on Linux -- ZFS, XFS, and Btrfs.
> 
>     I switched from ext2 to Reiserfs many years ago, when Reiser was the
> first and only journalled filesystem. After that switch I have never lost a
> file, while, before, I had lost full filesystems. I stick to the old
> reiserfs; I don't trust the new one.
> 
>     I'm reluctant to use ext3/ext4 because I don't understand why they still
> have this strange lost+found directory, which signs a kind of weakness.

:D That is kinda weird, come on! ext3/ext4 are solid fs, and have
always been. the lost+found folder is a remainder of the ext2 era, and
is not even mandatory any more, AFAIU.

I lost several filesystems with buggy reiserfs versions, back in the
days, and refused to use it ever again, basically because ext3 had
become reliable and dependable in the meanwhile. Then Hans Raiser
stopped its development, for other reasons... 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Lars Noodén]

On 12/28/2017 01:03 PM, Didier Kryn wrote:
[snip]>     From reading this thread, I learned that ZFS has severe hardware
> requirements; 
If all features are enabled then the RAM requirements are outrageous.
However, some of the memory hogs might not be missed if they are turned
off.  Depends on your use-cases though.

/Lars
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Didier Kryn]

Le 27/12/2017 à 01:05, Hendrik Boom a écrit :

As I understand it, there are a few new file systems somewhat
available on Linux -- ZFS, XFS, and Btrfs.


    I switched from ext2 to Reiserfs many years ago, when Reiser was 
the first and only journalled filesystem. After that switch I have never 
lost a file, while, before, I had lost full filesystems. I stick to the 
old reiserfs; I don't trust the new one.


    I'm reluctant to use ext3/ext4 because I don't understand why they 
still have this strange lost+found directory, which signs a kind of 
weakness.


    I have tried btrfs; it still runs on a few servers I have 
installed. I'm reluctant to continue with it because it is too tied to 
RedHat/Systemd and does too many things for my taste, RAID, compression, 
etc... I prefer to use mdadm for RAID - different tools for different 
tasks. I have stopped LVM long ago because I found it added a layer for 
almost no benefit.


    From reading this thread, I learned that ZFS has severe hardware 
requirements; therefore I'm also reluctant. Don't really know about XFS.


 I partially agree whith what has been said about RAID: it is 
essentially meant to ensure high availability. It doesn't provides all 
we expect from  backup: it does not protect against human errors or 
malevolent actions; yet it is a protection against the consequences of 
disk failure.


    Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Harald Arnesen]

Den 28.12.2017 01:51, skrev Steve Litt:

> The one downfall of my method is if you absolutely, positively need
> atomic backups: database files, for instance. You'd need to stop work
> on the computer being backed up. In the case of my Daily Driver
> Desktop, which contains 3,874,727 files, the entire backup takes about
> 5 minutes, the last 1.5 minutes of which is the cp -al phase, during
> which the computer being backed up can go an about its business.

Had you used btrfs instead, you could make a snapshot of your file system.
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Harald Arnesen (har...@skogtun.org):

> Den 27.12.2017 19:34, skrev taii...@gmx.com:
> 
> > Please remember that all RAID should have ECC RAM and when it comes to
> > XFS it is MANDATORY to avoid massive data corruption.
> 
> And a UPS.

To summarise the summary of the summary, concerning the above:  I think
many folks are not very good at understanding risk models.


ECC RAM is not sufficient to catch all bad RAM problems, only some.
Back in 2006, I had an interesting case of this:
http://linuxmafia.com/pipermail/conspire/2006-December/002662.html
http://linuxmafia.com/pipermail/conspire/2006-December/002668.html
http://linuxmafia.com/pipermail/conspire/2007-January/002743.html

I know most people won't bother to read that, so I'll summarise:  My VA
Linux Systems 2230 2U that was my prototype next-deployment server
showed a perplexing pattern of spontaneous reboots, even though all of
the 512MB of RAM was ECC SDRAM sticks on a server-grade ECC-supporting
Intel L440GX+ 'Lancewood' motherboard.  The RAM had also passed long
testing using memtest86.  Yet, something about the situation seemed to
still suggest one or more bad RAM stick.

As related in the mailing list links, I found the bad RAM using only logic
and stubborn use of iterative kernel compiles with 'make -j NN' cranked
high enough to exercise all the RAM.  (And no, it wasn't a bad memory
socket.  I was able to eliminate that.)


There are also far more worrisome causes of filesystem corruption than
bad RAM, not even counting software problems.  My one-time colleague Ted
T'so once wrote an excellent piece, that I can't find at the moment, 
about how ext2/ext3 code had necessarily been written with a defensive 
attitude, to compensate to the maximum possible extent for the ways
commodity PeeCee hardware tends to misbehave, e.g., the way cheap HBAs
often write random garbage inadvertently for a brief while in the
process of losing power when the system gets shut off.  T'so observed
that this risk model from commodity hardware didn't exist on, e.g., SGI 
hardware built to run IRIX, so the XFS filesystem code on IRIX didn't
need to protect against that form of loss, while ext2/ext3 did.

(It may be that XFS got improved in exactly that area in the years since
the Linux port.  I haven't used it since I ran Debian on it during
2001-2.)

Further food for thought:
https://nctritech.wordpress.com/2017/03/07/zfs-wont-save-you-fancy-filesystem-fanatics-need-to-get-a-clue-about-bit-rot-and-raid-5/

-- 
Cheers,There are only 10 types of people in this world -- 
Rick Moen  those who understand binary arithmetic and those who don't.
r...@linuxmafia.com
McQ!  (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Steve Litt]

On Tue, 26 Dec 2017 17:20:58 -0800
Rick Moen  wrote:

> Quoting Hendrik Boom (hend...@topoi.pooq.com):
> 
> > As I understand it, there are a few new file systems somewhat 
> > available on Linux -- ZFS, XFS, and Btrfs.
> > 
> > But soe are still under development, ZFS is pparently under a 
> > prolematic license, and I don't know about XFS.
> > 
> > I've onece heard about one of the new systems that one shouldn't 
> > bother using it unless one has at least 8 gigabytes of RAM.
> > 
> > Now, just how mature are these, how easily managed, how reliable.
> > 
> > I'll be populating a new device with a (I hope) high-reliablity
> > file system soon.  It doesn't have a lot of RAM, but the RAM does
> > have parity checking.
> > 
> > Long-term data preservation is more important than speed.
> > 
> > Currently on another system I'm using ext4 over LLVM over software 
> > RAID-1.  I know RAID isn't a reliable backup system; I make
> > separate off-line backups.  
> 
> Specifically, RAID isn't backup at all.  It's redundancy (except for
> varieties like RAID0 that aren't even that).  See:  'Backup
> Fallacies / Pitfalls' on http://linuxmafia.com/kb/Admin/
> 
> > What should I be considering for the new system?  The same?
> 
> You've just asked one of the more inherently debatable questions in
> all of Linux system administration.
> 
> I can only recommend that you study what the strengths and weaknesses,
> advantages and disadvantages, are of the various options at hand, and
> then design a system that implements your choices.
> 
> For my own home server rebuild, I'm going with ext4, with all
> filesystems RAID1-mirrored across a pair of SSDs, and a weekly cron
> job applying TRIM.  No swap (because SSDs).

Being a fan of simplicity, I use ext4 on all partitions. No LVM: I
don't want the extra layer. With things like bind mount I can
temporarily move parts of one filetree to a different partition, and
the next time I full-install or buy a new computer or something, I can
resize partitions accordingly.

ext4 is years old, proven reliable for years, has all the necess

I don't use disk encryption, but if I did I'd find a way to do it
without LVM.

I don't use RAID, and to the best of my knowledge I've never had data
silently go bad on me.

I use rsync backup from a backup server to get incrimental and full
backups at the same time via cp -al on the backup server. I back up
once or twice a week --- it should be every day. Every month or so I
copy the latest from the backup server to a couple Blu-Rays: One copy
is encrypted, the other copy is unencrypted and goes in my bank vault.

About what Hendrick asked: "Long-term data preservation is more
important than speed."

My system does almost everything Hendrick needs. The backups guard the
data, basically forever. The only issue is silent corruption. I'd
address that by a series of RAM tests and SMART tests twice a week,
just before the backup. If any new problems, look very carefully at any
changed files.

My backup scripts could be changed slightly to make some sort of
alphabetical list of all /path/filename.ext together with an md5sum, so
there could be an easy report on what changed between backups. If you
do this every day, you should get a pretty good idea whether the file
should have changed, and if not, investigate.

As somebody said, ECC RAM would certainly be helpful, but my experience
is that mobos that both accommodate ECC and run Linux are a lot more
expensive, which is fine if this is a corporate server but less so if
it's just your workstation. I'd still run a RAM check every week.

The one downfall of my method is if you absolutely, positively need
atomic backups: database files, for instance. You'd need to stop work
on the computer being backed up. In the case of my Daily Driver
Desktop, which contains 3,874,727 files, the entire backup takes about
5 minutes, the last 1.5 minutes of which is the cp -al phase, during
which the computer being backed up can go an about its business.

My system isn't for everybody, but for those wanting simplicity and
also short and long term reliability, it's pretty good.

SteveT

Steve Litt 
December 2017 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Alessandro Selli]

On Wed, 27 Dec 2017 at 21:59:27 +0100
Harald Arnesen  wrote:

> Den 27.12.2017 19:34, skrev taii...@gmx.com:
>
>> Please remember that all RAID should have ECC RAM and when it comes to
>> XFS it is MANDATORY to avoid massive data corruption.  
>
> And a UPS.

And an earthquake-proof vault to house the server farm.


Alessandro


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[taii...@gmx.com]

Please remember that all RAID should have ECC RAM and when it comes to 
XFS it is MANDATORY to avoid massive data corruption.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Harald Arnesen (har...@skogtun.org):

> Den 27.12.2017 02:20, skrev Rick Moen:
> 
> > btrfs is still scarily beta after rather a lot of years of development.
> > Its prospects have dimmed further now that Red Hat have dropped it from
> > their roadmap.
> 
> That's your opinion.

Nobody will be happier than I, if events prove me wrong in that view.

-- 
Cheers,  "Like running into a burning building and trying to put the
Rick Moen fire out by means of interpretive dance." -- Iain M. Banks
r...@linuxmafia.com   on alternative cancer treatments, after his own diagnosis
McQ! (4x80) www.theguardian.com/books/2013/jun/15/iain-banks-the-final-interview
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting KatolaZ (kato...@freaknet.org):

> IMHO Canonical is playing with fire with their (obviously wrong)
> interpretation of the querelle, since Oracle has never ever been a
> fair player...

My recollection is that the stakeholders whose copyright would be
infringed by an unauthorised derivative work, in this case, would be the
Linux kernel copyright owners, not Oracle as Sun Microsystems's
successors in interest.

(I say that from memory, not being willing to go re-read CDDL just to
check.)

-- 
Cheers,"I am not responsible for the structural integrity 
Rick Moen  of the bubble you've chosen to live in."
r...@linuxmafia.com   -- Mike Norton
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Harald Arnesen]

Den 27.12.2017 02:20, skrev Rick Moen:

> btrfs is still scarily beta after rather a lot of years of development.
> Its prospects have dimmed further now that Red Hat have dropped it from
> their roadmap.

That's your opinion.
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Hendrik Boom]

On Tue, Dec 26, 2017 at 09:50:07PM -0800, Josef Grosch wrote:
> On 12/26/17 6:22 PM, Hendrik Boom wrote:
> > On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
> >> Quoting Hendrik Boom (hend...@topoi.pooq.com):
> >>
> [ DELETED ]
> >
> > I'll have about half a gig of RAM.  Does this rule out ZFS or just 
> > make it moderately slower?  I'm not going to be running millions of 
> > transactions a day on my home server.
> 
> I am a long time user of ZFS on FreeBSD, Ubuntu, and Debian. This is my 
> opinion. My opinion and $5.00 will get you a Happy Meal. 
> 
> A good place to start is ZFS On Linux (http://zfsonlinux.org/) This project 
> is being run by the bright boys and girls at Lawrence Livermore National Lab, 
> our tax dollars at work. Yes, it is covered by a GPLv2-incompatible 
> licence[1] (CDDL), but I consider the advantages of ZFS enough to ignore the 
> license issue. I mostly run Debian and ZFS works like a charm.
> 
> The minimum amount of RAM you need to run ZFS is 8 gb BUT you will not be 
> happy. Realistically you should have a minimum of 16 gb. My ZFS at home has 
> 64 gb and is quite happy. Also you must be running a 64 bit OS. Another point 
> to keep in mind is that with RaidZ1 (RAID5) or RaidZ2 (RAID6) should never 
> get above 80% usage. 

The RAM requirement pretty well rules out ZFS for me.

Too bad.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[KatolaZ]

On Thu, Dec 28, 2017 at 01:42:56AM +1100, Andrew McGlashan wrote:

[cut]

> 
> You can legally, if I understand correctly, build ZFS in to a Linux
> Kernel yourself, but you cannot (due to license restriction), do so and
> provide it for others to use "as is", everyone whom want to use it in a
> Linux Kernel must compile it themselves.  That makes a mockery of
> Canonical's opinion, but perhaps they paid monies to Oracle to free it
> up for them somehow
>

It's true that you cannot distribute a Linux kernel with builtin ZFS
support, since the ZFS' license is incompatible with the GPL, but
thanks to dkms you don't need to recompile the Linux kernel to have
ZFS support built as a module (and included in your initramfs, if you
like).

IMHO Canonical is playing with fire with their (obviously wrong)
interpretation of the querelle, since Oracle has never ever been a
fair player...

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Andrew McGlashan]

Hi,

On 27/12/17 16:50, Josef Grosch wrote:
> A good place to start is ZFS On Linux (http://zfsonlinux.org/) This project 
> is being run by the bright boys and girls at Lawrence Livermore National Lab, 
> our tax dollars at work. Yes, it is covered by a GPLv2-incompatible 
> licence[1] (CDDL), but I consider the advantages of ZFS enough to ignore the 
> license issue. I mostly run Debian and ZFS works like a charm.

ZFS on Linux is different to ZFS in the Linux Kernel. each has it's
own license.  ZFS on Linux uses Fuse and is quite happily GPL.  I hate
the fact that Oracle bought Sun Microsystems and I wish they would
re-license any and all Sun code that should be fairly provided for the
community (especially anything to do with ZFS, especially since they
cared more about BTRFS anyway...).  Sun created ZFS, Oracle created
BTRFS, they are competing, ZFS should be the winner, but the CDDL
situation is a pain.

You can legally, if I understand correctly, build ZFS in to a Linux
Kernel yourself, but you cannot (due to license restriction), do so and
provide it for others to use "as is", everyone whom want to use it in a
Linux Kernel must compile it themselves.  That makes a mockery of
Canonical's opinion, but perhaps they paid monies to Oracle to free it
up for them somehow

Oh and I definitely think Oracle should give up on it's fight with
Google over Java -- Sun always meant it to be possible for anybody to
use unencumbered and they surely encouraged it; so it is my opinion that
Oracle should let it be (not that I am defending Google, but I
absolutely believe that Google is right here), however, I am not a
lawyer so take my opinion for what it is.

I would much prefer to have ext4 support checksumming too, but I can't
see that ever happening; if it does, it will be new works based on BTRFS
most likely and it'll be ext5 or something else.

My preference, if it was never a licensing issue, would be to use ZFS
with ECC RAM built-in to the Linux Kernel, but I am not rolling my own
kernel these days and am sticking with "stock" ones that come with my
distro.

Kind Regards
AndrewM



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Josef Grosch]

On 12/26/17 6:22 PM, Hendrik Boom wrote:
> On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
>> Quoting Hendrik Boom (hend...@topoi.pooq.com):
>>
[ DELETED ]
>
> I'll have about half a gig of RAM.  Does this rule out ZFS or just 
> make it moderately slower?  I'm not going to be running millions of 
> transactions a day on my home server.

I am a long time user of ZFS on FreeBSD, Ubuntu, and Debian. This is my 
opinion. My opinion and $5.00 will get you a Happy Meal. 

A good place to start is ZFS On Linux (http://zfsonlinux.org/) This project is 
being run by the bright boys and girls at Lawrence Livermore National Lab, our 
tax dollars at work. Yes, it is covered by a GPLv2-incompatible licence[1] 
(CDDL), but I consider the advantages of ZFS enough to ignore the license 
issue. I mostly run Debian and ZFS works like a charm.

The minimum amount of RAM you need to run ZFS is 8 gb BUT you will not be 
happy. Realistically you should have a minimum of 16 gb. My ZFS at home has 64 
gb and is quite happy. Also you must be running a 64 bit OS. Another point to 
keep in mind is that with RaidZ1 (RAID5) or RaidZ2 (RAID6) should never get 
above 80% usage. 

[ DELETED ]



Josef

-- 
Josef Grosch   |  Another day closer  |
jgro...@gmail.com  |  to Redwood Heaven   |  Berkeley, Ca.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

[RAID1:]

> It's not backup in any normally robust sense of the word.  It does 
> provide a bit of backup against one potential threat -- minor 
> localized hard drive failures.  

Which is properly called rendundancy, in contrast to backup.  (You might
continue to choose to differ, in which case we agree to disagree,
please.)

> That's why I also keep separate off-line backups.

Which is properly called backup.  ;->

> TRIM because SSDs?

That's what TRIM (capitalised not as an acronym but rather because it's
a style convention for the names of ATA commands) applies to.  Your
question lacks context and clarity as stated, so I don't know whether
you're saying you are fundamentally unfamiliar with the issue.  You
might be saying that.  If you are:

https://en.wikipedia.org/wiki/Trim_(computing)
https://wiki.debian.org/SSDOptimization
https://wiki.archlinux.org/index.php/Solid_State_Drives
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4519

Also covers block alignment and other issues raised by SSD.

> I like the checksum protection of ZFS and btrfs.  If I could get it 
> with ext4 I'd be happy.

Don't hold you breath waiting.  ;->

> I'll have about half a gig of RAM.  Does this rule out ZFS or just 
> make it moderately slower?  I'm not going to be running millions of 
> transactions a day on my home server.

I'm pretty sure it totally rules out ZFS.  The usual RAM suggestions 
start at 8GB, and go upwards from there.  It's possible to have a
crawling^W running system with less (like, as low as 1GB), but you
wouldn't like it.

[btrfs:]

> Scarily beta, yes.  I'd consider it if it ever stops being scarily 
> beta.

Don't hold you breath waiting.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Hendrik Boom]

On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
> Quoting Hendrik Boom (hend...@topoi.pooq.com):
> 
> > As I understand it, there are a few new file systems somewhat 
> > available on Linux -- ZFS, XFS, and Btrfs.
> > 
> > But soe are still under development, ZFS is pparently under a 
> > prolematic license, and I don't know about XFS.
> > 
> > I've onece heard about one of the new systems that one shouldn't 
> > bother using it unless one has at least 8 gigabytes of RAM.
> > 
> > Now, just how mature are these, how easily managed, how reliable.
> > 
> > I'll be populating a new device with a (I hope) high-reliablity file 
> > system soon.  It doesn't have a lot of RAM, but the RAM does have 
> > parity checking.
> > 
> > Long-term data preservation is more important than speed.
> > 
> > Currently on another system I'm using ext4 over LLVM over software 
> > RAID-1.  I know RAID isn't a reliable backup system; I make separate 
> > off-line backups.
> 
> Specifically, RAID isn't backup at all.  It's redundancy (except for
> varieties like RAID0 that aren't even that).  See:  'Backup Fallacies /
> Pitfalls' on http://linuxmafia.com/kb/Admin/

It's not backup in any normally robust sense of the word.  It does 
provide a bit of backup against one potential threat -- minor 
localized hard drive failures.  That's why I also keep separate 
off-line backups.

> 
> > What should I be considering for the new system?  The same?  
> 
> You've just asked one of the more inherently debatable questions in all
> of Linux system administration.

I know.

> 
> I can only recommend that you study what the strengths and weaknesses,
> advantages and disadvantages, are of the various options at hand, and
> then design a system that implements your choices.
> 
> For my own home server rebuild, I'm going with ext4, with all
> filesystems RAID1-mirrored across a pair of SSDs, and a weekly cron job
> applying TRIM.  No swap (because SSDs).

TRIM because SSDs?

> 
> XFS is mainline kernel code under GPLv2.  It is particularly good for
> filesystems with mny very large files, e.g., audio/video.  It isn't 
> quite as fast and massively QAed as ext3/ext4 (though the performance
> difference is smaller than it used to be) .  XFS is _not_ new.  SGI
> ported it to Linux in 2000.  Like ext3/ext4 and unlike ZFS/btrfs, XFS
> lacks checksum protection against silent data corruption.

I like the checksum protection of ZFS and btrfs.  If I could get it 
with ext4 I'd be happy.

> ZFS is indeed under a GPLv2-incompatible licence[1] (CDDL).  It's the one
> that requires larger RAM overhead, but has a number of very compelling
> features[2] especially for extremely large (multi-terabyte) filesystems.
> The driver code is (obviously) not part of the mainline kernel, but
> rather runnable either as a large external patchset or as a FUSE
> Filesystem in Userspace subsystem.  The latter has a performance
> penalty.  The former... entails running an out-of-tree kernel.

I'll have about half a gig of RAM.  Does this rule out ZFS or just 
make it moderately slower?  I'm not going to be running millions of 
transactions a day on my home server.

> 
> btrfs is still scarily beta after rather a lot of years of development.
> Its prospects have dimmed further now that Red Hat have dropped it from
> their roadmap.

Scarily beta, yes.  I'd consider it if it ever stops being scarily 
beta.

> 
> 
> [1] Canonical, Ltd. have asserted their recent distribution of
> binary-compiled ZFS module code for Ubuntu to be lawful.  My
> interpretation is that they know this is false, that it is clearly 
> copyright infringement, but have taken a calculated risk that kernel
> stakeholders won't sue them, and that the Linux-using public won't
> object overly to Canonical lying to them for PR advantage.
> 
> [2] Volume manager is integrated into the filesystmem.  Snapshots and
> replication built in.  All storage kept vetted by checksumming and as
> necessary corrected.  Automated self-healing.  Smarter data-striping
> ('ZRAID') than conventional RAID modes.  Native data compression /
> deduping (which, however, is RAM-hungry).  And a lot more: It's pretty
> impressive.



> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request file system reviews and recomendations.

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> As I understand it, there are a few new file systems somewhat 
> available on Linux -- ZFS, XFS, and Btrfs.
> 
> But soe are still under development, ZFS is pparently under a 
> prolematic license, and I don't know about XFS.
> 
> I've onece heard about one of the new systems that one shouldn't 
> bother using it unless one has at least 8 gigabytes of RAM.
> 
> Now, just how mature are these, how easily managed, how reliable.
> 
> I'll be populating a new device with a (I hope) high-reliablity file 
> system soon.  It doesn't have a lot of RAM, but the RAM does have 
> parity checking.
> 
> Long-term data preservation is more important than speed.
> 
> Currently on another system I'm using ext4 over LLVM over software 
> RAID-1.  I know RAID isn't a reliable backup system; I make separate 
> off-line backups.

Specifically, RAID isn't backup at all.  It's redundancy (except for
varieties like RAID0 that aren't even that).  See:  'Backup Fallacies /
Pitfalls' on http://linuxmafia.com/kb/Admin/

> What should I be considering for the new system?  The same?  

You've just asked one of the more inherently debatable questions in all
of Linux system administration.

I can only recommend that you study what the strengths and weaknesses,
advantages and disadvantages, are of the various options at hand, and
then design a system that implements your choices.

For my own home server rebuild, I'm going with ext4, with all
filesystems RAID1-mirrored across a pair of SSDs, and a weekly cron job
applying TRIM.  No swap (because SSDs).

XFS is mainline kernel code under GPLv2.  It is particularly good for
filesystems with mny very large files, e.g., audio/video.  It isn't 
quite as fast and massively QAed as ext3/ext4 (though the performance
difference is smaller than it used to be) .  XFS is _not_ new.  SGI
ported it to Linux in 2000.  Like ext3/ext4 and unlike ZFS/btrfs, XFS
lacks checksum protection against silent data corruption.

ZFS is indeed under a GPLv2-incompatible licence[1] (CDDL).  It's the one
that requires larger RAM overhead, but has a number of very compelling
features[2] especially for extremely large (multi-terabyte) filesystems.
The driver code is (obviously) not part of the mainline kernel, but
rather runnable either as a large external patchset or as a FUSE
Filesystem in Userspace subsystem.  The latter has a performance
penalty.  The former... entails running an out-of-tree kernel.

btrfs is still scarily beta after rather a lot of years of development.
Its prospects have dimmed further now that Red Hat have dropped it from
their roadmap.


[1] Canonical, Ltd. have asserted their recent distribution of
binary-compiled ZFS module code for Ubuntu to be lawful.  My
interpretation is that they know this is false, that it is clearly 
copyright infringement, but have taken a calculated risk that kernel
stakeholders won't sue them, and that the Linux-using public won't
object overly to Canonical lying to them for PR advantage.

[2] Volume manager is integrated into the filesystmem.  Snapshots and
replication built in.  All storage kept vetted by checksumming and as
necessary corrected.  Automated self-healing.  Smarter data-striping
('ZRAID') than conventional RAID modes.  Native data compression /
deduping (which, however, is RAM-hungry).  And a lot more: It's pretty
impressive.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng