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

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

recommendations for supported, affordable hardware raid controller.

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

Contents

  recommendations for supported, affordable hardware raid controller. Steven Mainor <steve@degga.net> - 2021-01-01 19:10 +0100
    Re: recommendations for supported, affordable hardware raid  controller. "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-01-01 20:00 +0100
    Re: recommendations for supported, affordable hardware raid  controller. Dan Ritter <dsr@randomstring.org> - 2021-01-01 20:00 +0100
      Re: recommendations for supported, affordable hardware raid controller. Sven Hartge <sven@svenhartge.de> - 2021-01-01 20:40 +0100
    Re: recommendations for supported, affordable hardware raid  controller. David Christensen <dpchrist@holgerdanske.com> - 2021-01-01 21:10 +0100
      Re: recommendations for supported, affordable hardware raid  controller. Steven Mainor <steve@degga.net> - 2021-01-02 09:30 +0100
        Re: recommendations for supported, affordable hardware raid  controller. Steven Mainor <steve@degga.net> - 2021-01-02 09:50 +0100
    Re: recommendations for supported, affordable hardware raid  controller. Michael Stone <mstone@debian.org> - 2021-01-01 21:20 +0100
    Re: recommendations for supported, affordable hardware raid  controller. Steven Mainor <steve@degga.net> - 2021-01-02 09:20 +0100
      Re: recommendations for supported, affordable hardware raid  controller. David Christensen <dpchrist@holgerdanske.com> - 2021-01-02 10:50 +0100
        Re: recommendations for supported, affordable hardware raid  controller. Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 12:30 +0100
          Re: recommendations for supported, affordable hardware raid  controller. Richard Hector <richard@walnut.gen.nz> - 2021-01-02 17:10 +0100
            Re: recommendations for supported, affordable hardware raid controller. Gene Heskett <gheskett@shentel.net> - 2021-01-02 17:50 +0100
          Re: recommendations for supported, affordable hardware raid  controller. David Christensen <dpchrist@holgerdanske.com> - 2021-01-02 22:40 +0100
            Re: recommendations for supported, affordable hardware raid  controller. Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-03 10:30 +0100
              Re: recommendations for supported, affordable hardware raid  controller. David Christensen <dpchrist@holgerdanske.com> - 2021-01-03 22:50 +0100
                Re: recommendations for supported, affordable hardware raid  controller. Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-04 08:30 +0100
              Re: recommendations for supported, affordable hardware raid controller. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-01-03 23:20 +0100
              Re: recommendations for supported, affordable hardware raid  controller. Michael Stone <mstone@debian.org> - 2021-01-04 02:00 +0100
                Re: recommendations for supported, affordable hardware raid  controller. Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-04 08:40 +0100
                  Re: recommendations for supported, affordable hardware raid  controller. Michael Stone <mstone@debian.org> - 2021-01-04 14:40 +0100
      Re: recommendations for supported, affordable hardware raid controller. Sven Hartge <sven@svenhartge.de> - 2021-01-02 12:50 +0100
        Re: recommendations for supported, affordable hardware raid controller. Nicholas Geovanis <nickgeovanis@gmail.com> - 2021-01-02 16:30 +0100
          Re: recommendations for supported, affordable hardware raid controller. Sven Hartge <sven@svenhartge.de> - 2021-01-02 17:30 +0100
          Re: recommendations for supported, affordable hardware raid  controller. Alain D D Williams <addw@phcomp.co.uk> - 2021-01-02 18:40 +0100
    Re: recommendations for supported, affordable hardware raid controller. deloptes <deloptes@gmail.com> - 2021-01-02 10:00 +0100

Page 1 of 2  [1] 2  Next page →

#230202 — recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

I'm looking for recommendations for a 6 or 8 port SATA hardware raid 
controller that will hopefully be supported by the kernel and/or open 
source drivers to put in my desktop computer. Any input welcome, thanks.

-- 
Steven Mainor

[toc] | [next] | [standalone]

#230204 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

On 01.01.2021 23:06, Steven Mainor wrote:
> I'm looking for recommendations for a 6 or 8 port SATA hardware raid 
> controller that will hopefully be supported by the kernel and/or open 
> source drivers to put in my desktop computer. Any input welcome, thanks.
>
Over the years I've been fond of RAID adapters from LSI Logic (now 
bought by Broadcom) [1] and Intel [2].
They have good support, nice and clean internal software used to manage 
arrays and settings.
However, depending on what your goals are, they could be an overkill for 
a desktop PC and you might be better look for HBA (Host Bus Adapter) to 
connect disks in JBOD (pass-through mode) and use software RAID 
solutions supported by OS of your choice.


[1] https://www.broadcom.com/products/storage
[2] https://www.intel.com/content/www/us/en/products/servers/raid.html

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

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

#230205 — Re: recommendations for supported, affordable hardware raid controller.

Steven Mainor wrote: 
> I'm looking for recommendations for a 6 or 8 port SATA hardware raid
> controller that will hopefully be supported by the kernel and/or open source
> drivers to put in my desktop computer. Any input welcome, thanks.

Having used them for 20+ years now, I strongly recommend against
hardware RAID controllers. Hardware SAS/SATA interfaces with
mdadm or ZFS are better in every one of my use cases.

That said, the best devices of these kinds are basically the
same:

LSI 2000 and 3000 series
Broadcom BR93xx
Areca anything
Carefully picked Adaptecs

-dsr-

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

#230206

Dan Ritter <dsr@randomstring.org> wrote:
> Steven Mainor wrote: 

>> I'm looking for recommendations for a 6 or 8 port SATA hardware raid
>> controller that will hopefully be supported by the kernel and/or open
>> source drivers to put in my desktop computer. Any input welcome,
>> thanks.

> Having used them for 20+ years now, I strongly recommend against
> hardware RAID controllers. Hardware SAS/SATA interfaces with mdadm or
> ZFS are better in every one of my use cases.

I second that motion.

Unless using Windows or ESXi outside VSAN you better avoid RAID
controllers. More hassle than gain, IMHO.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

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

#230207 — Re: recommendations for supported, affordable hardware raid controller.

On 2021-01-01 10:06, Steven Mainor wrote:
> I'm looking for recommendations for a 6 or 8 port SATA hardware raid 
> controller that will hopefully be supported by the kernel and/or open 
> source drivers to put in my desktop computer. Any input welcome, thanks.

Why?


What is your computer?


What Debian?


What Linux?


What application(s)?


What is your network/ environment?


David

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

#230220 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

> Why?
See my earlier email.

> What Debian?
Debian 10? Or 9? I'm mainly looking for options.

> What Linux?
Any still supported main-line or LTS Linux kernel.

> What application(s)?
General storage.

> What is your network/ environment?
Why is network information relevant for a RAID question?

---
Steven Mainor

On 2021-01-01 15:03, David Christensen wrote:
> On 2021-01-01 10:06, Steven Mainor wrote:
>> I'm looking for recommendations for a 6 or 8 port SATA hardware raid 
>> controller that will hopefully be supported by the kernel and/or open 
>> source drivers to put in my desktop computer. Any input welcome, 
>> thanks.
> 
> Why?
> 
> 
> What is your computer?
> 
> 
> What Debian?
> 
> 
> What Linux?
> 
> 
> What application(s)?
> 
> 
> What is your network/ environment?
> 
> 
> David

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

#230222 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

I missed this question in my last email. Apologies.

> What is your computer?
It is an Asus X470 Motherboard, AMD 2700x Processor
---
Steven Mainor

On 2021-01-02 03:24, Steven Mainor wrote:
>> Why?
> See my earlier email.
> 
>> What Debian?
> Debian 10? Or 9? I'm mainly looking for options.
> 
>> What Linux?
> Any still supported main-line or LTS Linux kernel.
> 
>> What application(s)?
> General storage.
> 
>> What is your network/ environment?
> Why is network information relevant for a RAID question?
> 
> ---
> Steven Mainor
> 
> On 2021-01-01 15:03, David Christensen wrote:
>> On 2021-01-01 10:06, Steven Mainor wrote:
>>> I'm looking for recommendations for a 6 or 8 port SATA hardware raid 
>>> controller that will hopefully be supported by the kernel and/or open 
>>> source drivers to put in my desktop computer. Any input welcome, 
>>> thanks.
>> 
>> Why?
>> 
>> 
>> What is your computer?
>> 
>> 
>> What Debian?
>> 
>> 
>> What Linux?
>> 
>> 
>> What application(s)?
>> 
>> 
>> What is your network/ environment?
>> 
>> 
>> David

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

#230208 — Re: recommendations for supported, affordable hardware raid controller.

On Fri, Jan 01, 2021 at 01:06:47PM -0500, Steven Mainor wrote:
>I'm looking for recommendations for a 6 or 8 port SATA hardware raid 
>controller that will hopefully be supported by the kernel and/or open 
>source drivers to put in my desktop computer. Any input welcome, 
>thanks.

Revenue generating system? Areca with a BBU. I wouldn't spend that much 
myself on a home system, and I also don't have a home system large 
enough that there'd be a noticeable performance difference even after 
spending the money. Where something like that is helpful is if you have 
a large number of disks in a RAID6--the nvram cache keeps the write 
performance from being terrible. There are ways to do that now with 
linux software RAID, but the additional complication and less common 
configuration makes the easy hardware solution very attractive. If 
you're doing RAID1 or you don't highly value small block write 
performance then the md software solution will do just as well. 
Depending on your requirements you might also consider lvm mirrors; the 
nice thing about those especially in a home environment is that you can 
selectively mirror critical data and stripe stuff you don't care if you 
lose and relatively easily reallocate storage between different 
strategies on the fly. 

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

#230219 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

All,

thanks for all the help so far. For all the people asking why, a few 
reasons. First I love to tinker with and learn about things and the only 
raid controller I have access to is on my production server and I don't 
really get to "play" with it much since it is in use 24/7. I am one of 
those people that learns by doing I guess.

The idea was to create a large striped raid array(perhaps RAID6) of 
spinning disks to use as a large storage area for extra VM backups and 
large projects I'm working on. And in the process I could learn more 
about RAID controllers.

But perhaps this would be an opportunity to learn about ZFS or something 
instead. Would ZFS be suitable if I were to boot multiple Linux 
operating systems from time to time? For example, If I have the drives 
setup with ZFS How hard would it be to boot to another Linux operating 
system (like from Debain or Ubuntu from a pen-drive) and access data on 
the "array".

And FYI most of the time I would still boot my computer from the single 
SSD that my OS is installed on.

---
Steven Mainor

On 2021-01-01 13:06, Steven Mainor wrote:
> I'm looking for recommendations for a 6 or 8 port SATA hardware raid
> controller that will hopefully be supported by the kernel and/or open
> source drivers to put in my desktop computer. Any input welcome,
> thanks.

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

#230232 — Re: recommendations for supported, affordable hardware raid controller.

On 2021-01-02 00:11, Steven Mainor wrote:
> All,
> 
> thanks for all the help so far. For all the people asking why, a few 
> reasons. First I love to tinker with and learn about things and the only 
> raid controller I have access to is on my production server and I don't 
> really get to "play" with it much since it is in use 24/7. I am one of 
> those people that learns by doing I guess.
> 
> The idea was to create a large striped raid array(perhaps RAID6) of 
> spinning disks to use as a large storage area for extra VM backups and 
> large projects I'm working on. And in the process I could learn more 
> about RAID controllers.
> 
> But perhaps this would be an opportunity to learn about ZFS or something 
> instead. 

Hardware vs. software RAID is a complex choice.  Each alternative has 
its benefits and drawbacks.  I'd suggest that you STFW for articles that 
compare and contrast the two for the kinds of goals you are trying to 
accomplish.


If you decide to go with hardware RAID, picking an identical card to 
what you already have, or a similar model from the same manufacturer, 
might have merit; if you like the card and it meets your needs.  This 
might allow you to leverage your knowledge of one to support both.


On Linux (including Debian), MD (multiple disk) and LVM (logical volume 
manager) are the obvious choices for software RAID.  Each have their 
respective learning curves, but they're not too high.


ZFS on Linux exists and works, but CDDL vs. GPL licensing issues prevent 
ZFS kernel support OOTB.  For data drives, using ZFS means installing 
the right drivers and/or userland tools.  But for ZFS-on-root system 
drives, AIUI the process requires more effort (STFW for instructions). 
When I wanted ZFS, I choose FreeBSD; the CDDL and BSD licenses allow ZFS 
kernel support OOTB, and ZFS is very well integrated into the OS.  ZFS 
has a larger learning curve than MD or LVM.


> Would ZFS be suitable if I were to boot multiple Linux 
> operating systems from time to time? For example, If I have the drives 
> setup with ZFS How hard would it be to boot to another Linux operating 
> system (like from Debain or Ubuntu from a pen-drive) and access data on 
> the "array".

So long as your OS of choice has ZFS support, then you can access ZFS 
datasets.


> And FYI most of the time I would still boot my computer from the single 
> SSD that my OS is installed on.

I also prefer to put one OS on one SSD, and I install trayless drive 
racks in my cases.


On 2021-01-02 00:24, Steven Mainor wrote:

 >> What Debian?
 > Debian 10? Or 9? I'm mainly looking for options.

If Debian 10 works on your hardware, use that.


 >> What Linux?
 > Any still supported main-line or LTS Linux kernel.

Assuming a 64-bit PC architecture, go with "amd64".


 >> What application(s)?
 > General storage.

You will get better results using a server for general storage than you 
will using a desktop.


You will get better results using a workstation for heavy workloads than 
you will using a desktop.


 >> What is your network/ environment?
 > Why is network information relevant for a RAID question?

Because you might be better off adding drives to a file server, adding 
another file server, and/or upgrading the connection between your 
desktop/ workstation and your storage box (faster LAN, specialized 
storage interconnect, whatever).


But for fast scratch storage for large amounts of data, local SSD's work 
very well.


On 2021-01-02 00:43, Steven Mainor wrote:
 > I missed this question in my last email. Apologies.
 >
 >> What is your computer?
 > It is an Asus X470 Motherboard, AMD 2700x Processor

Again -- You will get better results using a server for general storage 
than you will using a gaming desktop.


David

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

#230238 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

On Sb, 02 ian 21, 01:40:14, David Christensen wrote:
> 
> On Linux (including Debian), MD (multiple disk) and LVM (logical volume
> manager) are the obvious choices for software RAID.  Each have their
> respective learning curves, but they're not too high.

An interesting article I stumbled upon:
http://www.unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html

My take:

If you care about your data you should be using ZFS or btrfs. 

In case of data corruption (system crash, power outage, user error, or 
even just a HDD "hiccup") plain md without the dm-integrity layer won't 
even be able to tell which is the good data and will overwrite your good 
data with bad data. Silently.

ZFS appears to be better than btrfs in several ways (features, 
reliability, speed). Unfortunately you'll need at least an out-of-tree 
kernel module for that (package zfs-dkms).

For only a RAID1-type configuration btrfs might be good enough.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#230261 — Re: recommendations for supported, affordable hardware raid controller.

On 3/01/21 12:24 am, Andrei POPESCU wrote:
> On Sb, 02 ian 21, 01:40:14, David Christensen wrote:
>> 
>> On Linux (including Debian), MD (multiple disk) and LVM (logical volume
>> manager) are the obvious choices for software RAID.  Each have their
>> respective learning curves, but they're not too high.
> 
> An interesting article I stumbled upon:
> http://www.unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html

Hmm. It only talks about software raid in the context of RAID-5. They 
acknowledge that RAID-5 is 'frowned upon', but don't go into why, and 
say they think it's great. My take: once you've lost one disk, you have 
the same reliability as a RAID-0 (stripe) set of what's left - much less 
reliable than no RAID at all.

I generally stick with RAID-1, but would consider RAID-10.

> My take:
> 
> If you care about your data you should be using ZFS or btrfs.

Licensing issues and the resulting complications stop me using ZFS, and 
last I heard btrfs wasn't regarded as being as reliable as ext3/4 or xfs 
(I generally use xfs).

I may be out of date, and I've heard bad comments about xfs too ...

> In case of data corruption (system crash, power outage, user error, or
> even just a HDD "hiccup") plain md without the dm-integrity layer won't
> even be able to tell which is the good data and will overwrite your good
> data with bad data. Silently.

I guess I need to investigate that. Any further references? I've had 
crashes and power outages and never noticed any problems, not that that 
means they won't happen (or even that they haven't happened). Does a 
journalling filesystem on top not cover that?

Cheers,
Richard

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

#230263

On Saturday 02 January 2021 11:08:52 Richard Hector wrote:

> On 3/01/21 12:24 am, Andrei POPESCU wrote:
> > On Sb, 02 ian 21, 01:40:14, David Christensen wrote:
> >> On Linux (including Debian), MD (multiple disk) and LVM (logical
> >> volume manager) are the obvious choices for software RAID.  Each
> >> have their respective learning curves, but they're not too high.
> >
> > An interesting article I stumbled upon:
> > http://www.unixsheikh.com/articles/battle-testing-data-integrity-ver
> >ification-with-zfs-btrfs-and-mdadm-dm-integrity.html
>
> Hmm. It only talks about software raid in the context of RAID-5. They
> acknowledge that RAID-5 is 'frowned upon', but don't go into why, and
> say they think it's great. My take: once you've lost one disk, you
> have the same reliability as a RAID-0 (stripe) set of what's left -
> much less reliable than no RAID at all.
>
> I generally stick with RAID-1, but would consider RAID-10.
>
> > My take:
> >
> > If you care about your data you should be using ZFS or btrfs.
>
> Licensing issues and the resulting complications stop me using ZFS,
> and last I heard btrfs wasn't regarded as being as reliable as ext3/4
> or xfs (I generally use xfs).
>
> I may be out of date, and I've heard bad comments about xfs too ...
>
> > In case of data corruption (system crash, power outage, user error,
> > or even just a HDD "hiccup") plain md without the dm-integrity layer
> > won't even be able to tell which is the good data and will overwrite
> > your good data with bad data. Silently.
>
> I guess I need to investigate that. Any further references? I've had
> crashes and power outages and never noticed any problems, not that
> that means they won't happen (or even that they haven't happened).
> Does a journalling filesystem on top not cover that?
>
> Cheers,
> Richard

It should do an ok job IF you have a ups big enough to carry it till you 
can do a gracefull shutdown. Or NUT can do it for you. In my case I have 
a 1500WA APC ups, which carries everything but the printers for long 
enough to get the 20 kw nat gas fired generac in the back yard 
auto-started, 15 seconds max. When the overhead lights are off, I'm only 
aware of a power failure when the generac has started as that reboots 
the printers.

Without the UPS, a power failure just as the journal is being written, 
has a possibility of being incompleted or contaminated, but that is a 
pretty narrow time window. Milliseconds, and not very many by my SWAG. I 
have 4 other machines running 24/7 here, only one has a UPS, and despite 
the poor performance of my local power system, have not lost a byte to a 
power failure on any of them using ext4 file systems.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#230267 — Re: recommendations for supported, affordable hardware raid controller.

On 2021-01-02 03:24, Andrei POPESCU wrote:

> http://www.unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html

That looks interesting.  Thanks for the link.  :-)


On 2021-01-02 08:08, Richard Hector wrote:
> On 3/01/21 12:24 am, Andrei POPESCU wrote:
>> In case of data corruption (system crash, power outage, user error,
>> or even just a HDD "hiccup") plain md without the dm-integrity
>> layer won't even be able to tell which is the good data and will
>> overwrite your good data with bad data. Silently.

> I've had crashes and power outages and never noticed any problems,
> not that that means they won't happen (or even that they haven't
> happened). Does a journalling filesystem on top not cover that?

AIUI a journaling filesystem provides a two-step process to achieve 
atomic writes of multiple sectors to disk -- e.g. a process wants to put 
some data into a block here (say, a file), a block there (say, a 
directory), etc., and consistency of the on-disk data structures must be 
preserved.  The journal provides a two-step process whereby everything 
is written to the journal, then everything is written to disk.  If 
either step is interrupted, the filesystem driver will detect the 
failure and respond.  When done, either all of the blocks have been 
updated on disk or none of the blocks on disk have been changed.


Integrity checking addresses different failure modes by applying 
checksums to data blocks and metadata blocks.  If the contents of a 
block become corrupt, either in memory, in transit, on disk, etc., the 
driver will detect the failure and respond.  If redundant data is 
available, such as via RAID, the driver will correct the data and 
operations continue.  If no redundant data is available, the driver will 
generate an error.  File system layering features in the Linux kernel 
allow you to add the dm-integrity device mapper layer into a storage 
stack as desired:

https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html


On a related note, it is wise to have ECC memory to protect against data 
corruption in memory:

http://www.openoid.net/will-zfs-and-non-ecc-ram-kill-your-data/


More failure modes exist (potentially, an infinite number).  It's a 
question of what failure modes and effects concern you, and how much 
time and money you want to spend to mitigate risks.


David

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

#230279 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

On Sb, 02 ian 21, 13:35:06, David Christensen wrote:
> On 2021-01-02 03:24, Andrei POPESCU wrote:
> 
> > http://www.unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html
> 
> That looks interesting.  Thanks for the link.  :-)
> 
> 
> On 2021-01-02 08:08, Richard Hector wrote:
> > On 3/01/21 12:24 am, Andrei POPESCU wrote:
> > > In case of data corruption (system crash, power outage, user error,
> > > or even just a HDD "hiccup") plain md without the dm-integrity
> > > layer won't even be able to tell which is the good data and will
> > > overwrite your good data with bad data. Silently.
> 
> > I've had crashes and power outages and never noticed any problems,
> > not that that means they won't happen (or even that they haven't
> > happened). Does a journalling filesystem on top not cover that?
> 
> AIUI a journaling filesystem provides a two-step process to achieve atomic
> writes of multiple sectors to disk -- e.g. a process wants to put some data
> into a block here (say, a file), a block there (say, a directory), etc., and
> consistency of the on-disk data structures must be preserved.  The journal
> provides a two-step process whereby everything is written to the journal,
> then everything is written to disk.

That would mean all data is written to the disk twice and would make a 
journaling file system twice as slow compared to a non-journaling file 
system; the journal is typically on the same storage.

Even if you put the journal on another storage, having the data written 
there in parallel would basically result in a sort of RAID ;)

> If either step is interrupted, the
> filesystem driver will detect the failure and respond.  When done, either
> all of the blocks have been updated on disk or none of the blocks on disk
> have been changed.

My understanding of [1] is that the journal only keeps track of metadata 
and/or data *updates*.

In case of a crash it can only tell you whether the write was 
"completed". It has no way to know whether the data on disk is actually 
correct.

[1] https://en.wikipedia.org/wiki/Journaling_file_system

When using a non-checksumming file system we are trusting the storage to 
either return correct data or report a read error (bad block) in order 
to restore it from the "other" copies (in case of RAID) or, worst case, 
from backup.

If the storage returns *wrong* data instead a non-checksumming file 
system will never notice as it has no concept of what the correct data 
should be. 

A RAID by itself is also unable to distinguish between correct and 
incorrect data and may even overwrite the good data with the bad data.

If we are lucky the error is noticed *and* the backups contain the 
correct data (the backup may have been created from the corrupt data).

Without good integrity checks it is also very difficult to tell how 
probable such issues are.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#230300 — Re: recommendations for supported, affordable hardware raid controller.

On 2021-01-03 01:25, Andrei POPESCU wrote:
> On Sb, 02 ian 21, 13:35:06, David Christensen wrote:

>> AIUI a journaling filesystem provides a two-step process to achieve atomic
>> writes of multiple sectors to disk -- e.g. a process wants to put some data
>> into a block here (say, a file), a block there (say, a directory), etc., and
>> consistency of the on-disk data structures must be preserved.  The journal
>> provides a two-step process whereby everything is written to the journal,
>> then everything is written to disk.
> 
> That would mean all data is written to the disk twice and would make a
> journaling file system twice as slow compared to a non-journaling file
> system; the journal is typically on the same storage.
> 
> Even if you put the journal on another storage, having the data written
> there in parallel would basically result in a sort of RAID ;)
> 
>> If either step is interrupted, the
>> filesystem driver will detect the failure and respond.  When done, either
>> all of the blocks have been updated on disk or none of the blocks on disk
>> have been changed.
> 
> My understanding of [1] is that the journal only keeps track of metadata
> and/or data *updates*.
> 
> In case of a crash it can only tell you whether the write was
> "completed". It has no way to know whether the data on disk is actually
> correct.
> 
> [1] https://en.wikipedia.org/wiki/Journaling_file_system
> 
> When using a non-checksumming file system we are trusting the storage to
> either return correct data or report a read error (bad block) in order
> to restore it from the "other" copies (in case of RAID) or, worst case,
> from backup.
> 
> If the storage returns *wrong* data instead a non-checksumming file
> system will never notice as it has no concept of what the correct data
> should be.
> 
> A RAID by itself is also unable to distinguish between correct and
> incorrect data and may even overwrite the good data with the bad data.
> 
> If we are lucky the error is noticed *and* the backups contain the
> correct data (the backup may have been created from the corrupt data).
> 
> Without good integrity checks it is also very difficult to tell how
> probable such issues are.

Yes, data and metadata integrity checking is different than responding 
to errors report by integrated drive controllers and/or interface 
controllers.  They address different failure modes.  But Murphy's Law 
tells me there are others.


I would postulate that copy-on-write technology could be/ is already 
included in journaling file systems to improve efficiency.


As they say, "the devil is in the details".


But, I am not going to read a mountain of web pages/ books and/or crawl 
source code to find out.  As a computer user and hobbyist developer, my 
challenges are learning what is available OOTB at a sufficient level to 
choose the appropriate pieces for, and apply them correctly to, my 
needs.  My primary metrics are correctness and stability; I avoid 
"bleeding edge", "testing", "unstable", etc..  I must rely on other 
people to develop, test, document, package, and support what I use.


I await dm-integrity being included in the Debian Installer.


Ubuntu figured out how to do ZFS-on-root OOTB; I wish Debian would do 
the same.


David

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

#230314 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

On Du, 03 ian 21, 13:43:00, David Christensen wrote:
> 
> I would postulate that copy-on-write technology could be/ is already
> included in journaling file systems to improve efficiency.

Copy-on-write (btrfs, ZFS) is different than journaling (ext4, xfs, 
etc.).

As fas as I understand copy-on-write provides the same file system 
consistency guarantees as a journal, but has other benefits in addition.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#230301

>> AIUI a journaling filesystem provides a two-step process to achieve atomic
>> writes of multiple sectors to disk -- e.g. a process wants to put some data
>> into a block here (say, a file), a block there (say, a directory), etc., and
>> consistency of the on-disk data structures must be preserved.  The journal
>> provides a two-step process whereby everything is written to the journal,
>> then everything is written to disk.
> That would mean all data is written to the disk twice and would make a
> journaling file system twice as slow compared to a non-journaling file
> system; the journal is typically on the same storage.

On rotating storage, it's definitely not that bad, since typically every
file modification will involve several parts of the disk (at least the
actual data and the inode, and often more), so the log only adds one
head movement to the 2 or 3 already needed.  Furthermore, once it's
written to the log, there is no hurry to do the other writes, so they
can be delayed and coalesced with other nearby writes, reducing head
movement yet further.

So, all in all, the performance impact can be quite varied and will
heavily depend on your use case (and on how much work went into tuning
the filesystem and journaling code).


        Stefan

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

#230306 — Re: recommendations for supported, affordable hardware raid controller.

On Sun, Jan 03, 2021 at 11:25:40AM +0200, Andrei POPESCU wrote:
>That would mean all data is written to the disk twice and would make a
>journaling file system twice as slow compared to a non-journaling file
>system; the journal is typically on the same storage.

That's almost never how it's actually implemented these days, exactly 
because of the hideous performance penalty. Barring a non-default option 
like ext3's data=journal what generally happens is that the data is 
written to the disk, then the *metadata* is written to the journal, and 
then the metadata is updated in its final location. The total amount of 
data written to the journal is relatively low. The primary benefit of 
this sort of scheme is avoiding a fsck on unclean shutdown; you may end 
up with old data, new data, or partially written data. Applications 
which need more data integrity guarantees generally implement some sort 
of journalling and/or use atomic filesystem operations. (E.g., write a 
temporary file, flush/sync, rename--that guarantees either the old file or 
the new file will be present, but not a partially written file.)

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

#230315 — Re: recommendations for supported, affordable hardware raid controller.

[Multipart message — attachments visible in raw view] — view raw

On Du, 03 ian 21, 19:53:07, Michael Stone wrote:
> 
> Applications which need more data integrity
> guarantees generally implement some sort of journalling and/or use atomic
> filesystem operations. (E.g., write a temporary file, flush/sync,
> rename--that guarantees either the old file or the new file will be present,
> but not a partially written file.)

Unless I'm mistaken, this is somewhat similar to how copy-on-write works 
for every write, except that the copy-on-write is done at block level 
and with the added benefits that unchanged blocks are kept as they are 
(less writes) and may even be shared between files (using less space).


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web