[nlug] useful command o' the day

[Howard White]

Currently messing about with a software raid (md).  Found a nice how-to



that included a couple of generally useful commands:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

and

cat /prod/mdstat


Enjoy.

Howard

--
--
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups "NLUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to nlug-talk+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nlug] useful command o' the day

[Steve]

The downside to MD/LVM vs a good raid controller is the caching. Hardware raid 
while is infact vendor specific offers battery backed ram as a read and write 
buffer. For spinning disk you’ll get more than twice the performance on a good 
raid controller.

All that to say if you don’t need performance, LVM is my preference. Even if I 
had a raid controller I would still run LVM on the linux host. Infact we ran 
LVM on every linux box (> 600vms) at my last place. It gives you the ability to 
resize partitions live and resize2fs lets you grow the filesystem in top of it.

In retrospect, I run MD at my home nas, I only have 4 sata ports and I was 
running 4x 4TB and I wanted to upgrade them all to 6TB. It was a painful 
process to say the least. I ran into md format (version) limits on bigger 
drives, superblock issues, all in all it took me about 3 weeks to finally get 
all the drives migrates over (1 drive out, after rebuild, 1 drive in, rebuild, 
repeat) it would have been about 4 days to do that on LVM.

Another benefit to LVM is snapshots! You can backup mysql in production by 
locking then flushing tables, lvm snapshot then release the lock. All that 
happens in under a second. (Way better than VSS for mssql)

My 2 cents.

Steve Wakham

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nlug-talk+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [nlug] useful command o' the day

[Chris McQuistion]

and if you "watch cat /proc/mdstat", you can watch the progress as your
RAID array is built or re-built.

*Chris McQuistion*

Director of Information Technology

Currey Ingram Academy

6544 Murray Lane, Brentwood, TN, 37027

*o* 615.507.3175   *c* 615.525.5877

www.curreyingram.org






On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:

> Currently messing about with a software raid (md).  Found a nice how-to
>
> <
> https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-16-04
> >
>
> that included a couple of generally useful commands:
>
> lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
>
> and
>
> cat /prod/mdstat
>
>
> Enjoy.
>
> Howard
>
> --
> --
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To post to this group, send email to nlug-talk@googlegroups.com
> To unsubscribe from this group, send email to
> nlug-talk+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nlug-talk?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nlug-talk+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nlug-talk+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [nlug] useful command o' the day

[Csaba Toth]

Would you favor LVM over "hardware" (quote is half intentional)? My twin
brother's advice is that this way I can avoid vendor lock-in. And if
something goes south I can still migrate to anything which provides JBOD.



On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion <
chris.mcquist...@curreyingram.org> wrote:

> and if you "watch cat /proc/mdstat", you can watch the progress as your
> RAID array is built or re-built.
>
> *Chris McQuistion*
>
> Director of Information Technology
>
> Currey Ingram Academy
>
> 6544 Murray Lane, Brentwood, TN, 37027
> 
>
>
> *o* 615.507.3175   *c* 615.525.5877
>
> www.curreyingram.org
>
>
>
>
>
>
> On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:
>
>> Currently messing about with a software raid (md).  Found a nice how-to
>>
>> > create-raid-arrays-with-mdadm-on-ubuntu-16-04>
>>
>> that included a couple of generally useful commands:
>>
>> lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
>>
>> and
>>
>> cat /prod/mdstat
>>
>>
>> Enjoy.
>>
>> Howard
>>
>> --
>> --
>> You received this message because you are subscribed to the Google Groups
>> "NLUG" group.
>> To post to this group, send email to nlug-talk@googlegroups.com
>> To unsubscribe from this group, send email to nlug-talk+unsubscribe@
>> googlegroups.com
>> For more options, visit this group at http://groups.google.com/
>> group/nlug-talk?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "NLUG" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nlug-talk+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To post to this group, send email to nlug-talk@googlegroups.com
> To unsubscribe from this group, send email to nlug-talk+unsubscribe@
> googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/nlug-talk?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nlug-talk+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nlug-talk+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [nlug] useful command o' the day

[Chris McQuistion]

I don’t think of Linux software RAID as the same as LVM but yes I would prefer 
Linux software RAID over hardware RAID because the performance is very good and 
the array is portable. I had a hardware RAID card die on me, many years ago, 
and it made me realize that I was dependent on that single piece of hardware 
that the manufacturer (Adaptec) had long since discontinued. 

Sent from my iPhone

> On Jun 8, 2018, at 7:54 PM, Csaba Toth  wrote:
> 
> Would you favor LVM over "hardware" (quote is half intentional)? My twin 
> brother's advice is that this way I can avoid vendor lock-in. And if 
> something goes south I can still migrate to anything which provides JBOD.
> 
> 
> 
>> On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion 
>>  wrote:
>> and if you "watch cat /proc/mdstat", you can watch the progress as your RAID 
>> array is built or re-built.
>> 
>> Chris McQuistion
>> Director of Information Technology
>> Currey Ingram Academy
>> 6544 Murray Lane, Brentwood, TN, 37027 
>> o 615.507.3175   c 615.525.5877
>> www.curreyingram.org 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:
>>> Currently messing about with a software raid (md).  Found a nice how-to
>>> 
>>> 
>>> 
>>> that included a couple of generally useful commands:
>>> 
>>> lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
>>> 
>>> and
>>> 
>>> cat /prod/mdstat
>>> 
>>> 
>>> Enjoy.
>>> 
>>> Howard
>>> 
>>> -- 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "NLUG" group.
>>> To post to this group, send email to nlug-talk@googlegroups.com
>>> To unsubscribe from this group, send email to 
>>> nlug-talk+unsubscr...@googlegroups.com
>>> For more options, visit this group at 
>>> http://groups.google.com/group/nlug-talk?hl=en
>>> 
>>> --- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "NLUG" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to nlug-talk+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "NLUG" group.
>> To post to this group, send email to nlug-talk@googlegroups.com
>> To unsubscribe from this group, send email to 
>> nlug-talk+unsubscr...@googlegroups.com
>> For more options, visit this group at 
>> http://groups.google.com/group/nlug-talk?hl=en
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "NLUG" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to nlug-talk+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "NLUG" group.
> To post to this group, send email to nlug-talk@googlegroups.com
> To unsubscribe from this group, send email to 
> nlug-talk+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/nlug-talk?hl=en
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "NLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to nlug-talk+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nlug-talk+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [nlug] useful command o' the day

[Csaba Toth]

True. LVM is not remotely equivalent, but can be utilized towards use cases
of disk arrays. A well versed RAID controller makes it easy to set up a
RAID 50 for example but as you experienced, they can age and things can go
wrong. Some of them are true hardware RAID, like lats time I dealt with an
AMCC which has PowerPC CPU on board to perform the parity computations and
related stuff. But for today's CPUs that's not much. If you have enough
spare cards that can be enough fine.
One thing I also learned long time ago: make sure to have a BBU and that
the BBU battery is charged & functional, otherwise you can be impacted by a
significant speed hit because the card won't cache as much / caches
differently for data integrity reasons.

On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion  wrote:

> I don’t think of Linux software RAID as the same as LVM but yes I would
> prefer Linux software RAID over hardware RAID because the performance is
> very good and the array is portable. I had a hardware RAID card die on me,
> many years ago, and it made me realize that I was dependent on that single
> piece of hardware that the manufacturer (Adaptec) had long since
> discontinued.
>
> Sent from my iPhone
>
> On Jun 8, 2018, at 7:54 PM, Csaba Toth  wrote:
>
> Would you favor LVM over "hardware" (quote is half intentional)? My twin
> brother's advice is that this way I can avoid vendor lock-in. And if
> something goes south I can still migrate to anything which provides JBOD.
>
>
>
> On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion  curreyingram.org> wrote:
>
>> and if you "watch cat /proc/mdstat", you can watch the progress as your
>> RAID array is built or re-built.
>>
>> *Chris McQuistion*
>>
>> Director of Information Technology
>>
>> Currey Ingram Academy
>>
>> 6544 Murray Lane, Brentwood, TN, 37027
>> 
>>
>>
>> *o* 615.507.3175   *c* 615.525.5877
>>
>> www.curreyingram.org
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:
>>
>>> Currently messing about with a software raid (md).  Found a nice how-to
>>>
>>> >> ate-raid-arrays-with-mdadm-on-ubuntu-16-04>
>>>
>>> that included a couple of generally useful commands:
>>>
>>> lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
>>>
>>> and
>>>
>>> cat /prod/mdstat
>>>
>>>
>>> Enjoy.
>>>
>>> Howard
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "NLUG" group.
>>> To post to this group, send email to nlug-talk@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> nlug-talk+unsubscr...@googlegroups.com
>>> For more options, visit this group at http://groups.google.com/group
>>> /nlug-talk?hl=en
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "NLUG" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to nlug-talk+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> --
>> You received this message because you are subscribed to the Google Groups
>> "NLUG" group.
>> To post to this group, send email to nlug-talk@googlegroups.com
>> To unsubscribe from this group, send email to
>> nlug-talk+unsubscr...@googlegroups.com
>> For more options, visit this group at http://groups.google.com/group
>> /nlug-talk?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "NLUG" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nlug-talk+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> --
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To post to this group, send email to nlug-talk@googlegroups.com
> To unsubscribe from this group, send email to nlug-talk+unsubscribe@
> googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/nlug-talk?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nlug-talk+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To post to this group, send email to nlug-talk@googlegroups.com
> To unsubscribe from this group, send email to nlug-talk+unsubscribe@
> googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/nlug-talk?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "NLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nlug-talk+unsubscr...@googlegroups.com.
> For more options, visi

Re: [nlug] useful command o' the day

[Tilghman Lesher]

When I think of vendor lock-in, I generally think of the inability to move
data off of one system.  I don't think that's really much of a concern, at
least if you're working with business systems, and your hardware is not
more than a few years old.  As the disks tend to fail more often than the
controller, how you formatted and managed the disks isn't likely to be the
main issue.

The bigger issue that you're going to encounter is a change in hardware
specification.  Imagine that you have a storage room full of IDE disks, and
you needed to get information off of them, when today, the prevailing
standard is SATA.  Or, if you're into tape backups, imagine a room full of
backup tapes and being unable to find a working drive that takes that
specific tape.

On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth  wrote:

> True. LVM is not remotely equivalent, but can be utilized towards use
> cases of disk arrays. A well versed RAID controller makes it easy to set up
> a RAID 50 for example but as you experienced, they can age and things can
> go wrong. Some of them are true hardware RAID, like lats time I dealt with
> an AMCC which has PowerPC CPU on board to perform the parity computations
> and related stuff. But for today's CPUs that's not much. If you have enough
> spare cards that can be enough fine.
> One thing I also learned long time ago: make sure to have a BBU and that
> the BBU battery is charged & functional, otherwise you can be impacted by a
> significant speed hit because the card won't cache as much / caches
> differently for data integrity reasons.
>
> On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion <
> chris.mcquist...@gmail.com> wrote:
>
>> I don’t think of Linux software RAID as the same as LVM but yes I would
>> prefer Linux software RAID over hardware RAID because the performance is
>> very good and the array is portable. I had a hardware RAID card die on me,
>> many years ago, and it made me realize that I was dependent on that single
>> piece of hardware that the manufacturer (Adaptec) had long since
>> discontinued.
>>
>> Sent from my iPhone
>>
>> On Jun 8, 2018, at 7:54 PM, Csaba Toth  wrote:
>>
>> Would you favor LVM over "hardware" (quote is half intentional)? My twin
>> brother's advice is that this way I can avoid vendor lock-in. And if
>> something goes south I can still migrate to anything which provides JBOD.
>>
>>
>>
>> On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion <
>> chris.mcquist...@curreyingram.org> wrote:
>>
>>> and if you "watch cat /proc/mdstat", you can watch the progress as your
>>> RAID array is built or re-built.
>>>
>>> *Chris McQuistion*
>>>
>>> Director of Information Technology
>>>
>>> Currey Ingram Academy
>>>
>>> 6544 Murray Lane, Brentwood, TN, 37027
>>> 
>>>
>>>
>>> *o* 615.507.3175   *c* 615.525.5877
>>>
>>> www.curreyingram.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:
>>>
 Currently messing about with a software raid (md).  Found a nice how-to

 

 that included a couple of generally useful commands:

 lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

 and

 cat /prod/mdstat


 Enjoy.

 Howard

 --
 --
 You received this message because you are subscribed to the Google
 Groups "NLUG" group.
 To post to this group, send email to nlug-talk@googlegroups.com
 To unsubscribe from this group, send email to
 nlug-talk+unsubscr...@googlegroups.com
 For more options, visit this group at http://groups.google.com/group
 /nlug-talk?hl=en

 ---
 You received this message because you are subscribed to the Google
 Groups "NLUG" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to nlug-talk+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "NLUG" group.
>>> To post to this group, send email to nlug-talk@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> nlug-talk+unsubscr...@googlegroups.com
>>> For more options, visit this group at http://groups.google.com/group
>>> /nlug-talk?hl=en
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "NLUG" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to nlug-talk+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google Groups
>> "NLUG" group.
>> To post to this group, send email to nlug-talk@googlegroups.com
>> To unsubscribe from this group, send email to
>> nlug-talk+unsubscr...@g

Re: [nlug] useful command o' the day

[Csaba Toth]

My definition of the vendor lock-in is the same. Controller failure is much
less common than than disk failure, but when it happens it can be bad. In
such case moving off the data may not be easy, the controller knew how it
calculated and stored the parity. It's not a rocket science and it can be
forensically determined I guess, but that may require non trivial effort.
I've heard of a PACS system where the controller failure was forgotten out
of the contract (between the hospital and the vendor), but it happened and
it was NOT pretty.

With LVM it's all software, so you don't even have to move the data off, if
you find any controller with JBOD capability which can show the disks again
to the system.

I also often come across systems which 10+ years old, still running fine,
but the controllers become my first thought in my mind. The best if you
have some spare one. Still SATA, but yes, PATA for example is getting
really outdated.


On Mon, Jun 11, 2018, 9:46 AM Tilghman Lesher  wrote:

> When I think of vendor lock-in, I generally think of the inability to move
> data off of one system.  I don't think that's really much of a concern, at
> least if you're working with business systems, and your hardware is not
> more than a few years old.  As the disks tend to fail more often than the
> controller, how you formatted and managed the disks isn't likely to be the
> main issue.
>
> The bigger issue that you're going to encounter is a change in hardware
> specification.  Imagine that you have a storage room full of IDE disks, and
> you needed to get information off of them, when today, the prevailing
> standard is SATA.  Or, if you're into tape backups, imagine a room full of
> backup tapes and being unable to find a working drive that takes that
> specific tape.
>
> On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth 
> wrote:
>
>> True. LVM is not remotely equivalent, but can be utilized towards use
>> cases of disk arrays. A well versed RAID controller makes it easy to set up
>> a RAID 50 for example but as you experienced, they can age and things can
>> go wrong. Some of them are true hardware RAID, like lats time I dealt with
>> an AMCC which has PowerPC CPU on board to perform the parity computations
>> and related stuff. But for today's CPUs that's not much. If you have enough
>> spare cards that can be enough fine.
>> One thing I also learned long time ago: make sure to have a BBU and that
>> the BBU battery is charged & functional, otherwise you can be impacted by a
>> significant speed hit because the card won't cache as much / caches
>> differently for data integrity reasons.
>>
>> On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion <
>> chris.mcquist...@gmail.com> wrote:
>>
>>> I don’t think of Linux software RAID as the same as LVM but yes I would
>>> prefer Linux software RAID over hardware RAID because the performance is
>>> very good and the array is portable. I had a hardware RAID card die on me,
>>> many years ago, and it made me realize that I was dependent on that single
>>> piece of hardware that the manufacturer (Adaptec) had long since
>>> discontinued.
>>>
>>> Sent from my iPhone
>>>
>>> On Jun 8, 2018, at 7:54 PM, Csaba Toth  wrote:
>>>
>>> Would you favor LVM over "hardware" (quote is half intentional)? My twin
>>> brother's advice is that this way I can avoid vendor lock-in. And if
>>> something goes south I can still migrate to anything which provides JBOD.
>>>
>>>
>>>
>>> On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion <
>>> chris.mcquist...@curreyingram.org> wrote:
>>>
 and if you "watch cat /proc/mdstat", you can watch the progress as your
 RAID array is built or re-built.

 *Chris McQuistion*

 Director of Information Technology

 Currey Ingram Academy

 6544 Murray Lane, Brentwood, TN, 37027
 


 *o* 615.507.3175   *c* 615.525.5877

 www.curreyingram.org






 On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:

> Currently messing about with a software raid (md).  Found a nice how-to
>
> <
> https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-16-04
> >
>
> that included a couple of generally useful commands:
>
> lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
>
> and
>
> cat /prod/mdstat
>
>
> Enjoy.
>
> Howard
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "NLUG" group.
> To post to this group, send email to nlug-talk@googlegroups.com
> To unsubscribe from this group, send email to
> nlug-talk+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nlug-talk?hl=en
>
> ---
> You received this message because you are subscribed to the Google
> Groups "NLUG" group.

Re: [nlug] useful command o' the day

[Tilghman Lesher]

All of that is moot if you're keeping offline backups (and maybe even
offsite backups?  Right?  Right?), as the backup ensures that even if the
original system becomes completely unavailable, you still have your
applications and data.

On Thu, Jun 14, 2018 at 1:37 AM, Csaba Toth  wrote:

> My definition of the vendor lock-in is the same. Controller failure is
> much less common than than disk failure, but when it happens it can be bad.
> In such case moving off the data may not be easy, the controller knew how
> it calculated and stored the parity. It's not a rocket science and it can
> be forensically determined I guess, but that may require non trivial
> effort. I've heard of a PACS system where the controller failure was
> forgotten out of the contract (between the hospital and the vendor), but it
> happened and it was NOT pretty.
>
> With LVM it's all software, so you don't even have to move the data off,
> if you find any controller with JBOD capability which can show the disks
> again to the system.
>
> I also often come across systems which 10+ years old, still running fine,
> but the controllers become my first thought in my mind. The best if you
> have some spare one. Still SATA, but yes, PATA for example is getting
> really outdated.
>
>
> On Mon, Jun 11, 2018, 9:46 AM Tilghman Lesher 
> wrote:
>
>> When I think of vendor lock-in, I generally think of the inability to
>> move data off of one system.  I don't think that's really much of a
>> concern, at least if you're working with business systems, and your
>> hardware is not more than a few years old.  As the disks tend to fail more
>> often than the controller, how you formatted and managed the disks isn't
>> likely to be the main issue.
>>
>> The bigger issue that you're going to encounter is a change in hardware
>> specification.  Imagine that you have a storage room full of IDE disks, and
>> you needed to get information off of them, when today, the prevailing
>> standard is SATA.  Or, if you're into tape backups, imagine a room full of
>> backup tapes and being unable to find a working drive that takes that
>> specific tape.
>>
>> On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth 
>> wrote:
>>
>>> True. LVM is not remotely equivalent, but can be utilized towards use
>>> cases of disk arrays. A well versed RAID controller makes it easy to set up
>>> a RAID 50 for example but as you experienced, they can age and things can
>>> go wrong. Some of them are true hardware RAID, like lats time I dealt with
>>> an AMCC which has PowerPC CPU on board to perform the parity computations
>>> and related stuff. But for today's CPUs that's not much. If you have enough
>>> spare cards that can be enough fine.
>>> One thing I also learned long time ago: make sure to have a BBU and that
>>> the BBU battery is charged & functional, otherwise you can be impacted by a
>>> significant speed hit because the card won't cache as much / caches
>>> differently for data integrity reasons.
>>>
>>> On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion <
>>> chris.mcquist...@gmail.com> wrote:
>>>
 I don’t think of Linux software RAID as the same as LVM but yes I would
 prefer Linux software RAID over hardware RAID because the performance is
 very good and the array is portable. I had a hardware RAID card die on me,
 many years ago, and it made me realize that I was dependent on that single
 piece of hardware that the manufacturer (Adaptec) had long since
 discontinued.

 Sent from my iPhone

 On Jun 8, 2018, at 7:54 PM, Csaba Toth  wrote:

 Would you favor LVM over "hardware" (quote is half intentional)? My
 twin brother's advice is that this way I can avoid vendor lock-in. And if
 something goes south I can still migrate to anything which provides JBOD.



 On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion >>> curreyingram.org> wrote:

> and if you "watch cat /proc/mdstat", you can watch the progress as
> your RAID array is built or re-built.
>
> *Chris McQuistion*
>
> Director of Information Technology
>
> Currey Ingram Academy
>
> 6544 Murray Lane, Brentwood, TN, 37027
> 
>
>
> *o* 615.507.3175   *c* 615.525.5877
>
> www.curreyingram.org
>
>
>
>
>
>
> On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:
>
>> Currently messing about with a software raid (md).  Found a nice
>> how-to
>>
>> > create-raid-arrays-with-mdadm-on-ubuntu-16-04>
>>
>> that included a couple of generally useful commands:
>>
>> lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
>>
>> and
>>
>> cat /prod/mdstat
>>
>>
>> Enjoy.
>>
>> Howard
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>

Re: [nlug] useful command o' the day

[Chris McQuistion]

Always a good point.  There is NO REPLACEMENT for proper backups!

*Chris McQuistion*

Director of Information Technology

Currey Ingram Academy

6544 Murray Lane, Brentwood, TN, 37027

*o* 615.507.3175   *c* 615.525.5877

www.curreyingram.org






On Thu, Jun 14, 2018 at 9:14 AM Tilghman Lesher 
wrote:

> All of that is moot if you're keeping offline backups (and maybe even
> offsite backups?  Right?  Right?), as the backup ensures that even if the
> original system becomes completely unavailable, you still have your
> applications and data.
>
> On Thu, Jun 14, 2018 at 1:37 AM, Csaba Toth 
> wrote:
>
>> My definition of the vendor lock-in is the same. Controller failure is
>> much less common than than disk failure, but when it happens it can be bad.
>> In such case moving off the data may not be easy, the controller knew how
>> it calculated and stored the parity. It's not a rocket science and it can
>> be forensically determined I guess, but that may require non trivial
>> effort. I've heard of a PACS system where the controller failure was
>> forgotten out of the contract (between the hospital and the vendor), but it
>> happened and it was NOT pretty.
>>
>> With LVM it's all software, so you don't even have to move the data off,
>> if you find any controller with JBOD capability which can show the disks
>> again to the system.
>>
>> I also often come across systems which 10+ years old, still running fine,
>> but the controllers become my first thought in my mind. The best if you
>> have some spare one. Still SATA, but yes, PATA for example is getting
>> really outdated.
>>
>>
>> On Mon, Jun 11, 2018, 9:46 AM Tilghman Lesher 
>> wrote:
>>
>>> When I think of vendor lock-in, I generally think of the inability to
>>> move data off of one system.  I don't think that's really much of a
>>> concern, at least if you're working with business systems, and your
>>> hardware is not more than a few years old.  As the disks tend to fail more
>>> often than the controller, how you formatted and managed the disks isn't
>>> likely to be the main issue.
>>>
>>> The bigger issue that you're going to encounter is a change in hardware
>>> specification.  Imagine that you have a storage room full of IDE disks, and
>>> you needed to get information off of them, when today, the prevailing
>>> standard is SATA.  Or, if you're into tape backups, imagine a room full of
>>> backup tapes and being unable to find a working drive that takes that
>>> specific tape.
>>>
>>> On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth 
>>> wrote:
>>>
 True. LVM is not remotely equivalent, but can be utilized towards use
 cases of disk arrays. A well versed RAID controller makes it easy to set up
 a RAID 50 for example but as you experienced, they can age and things can
 go wrong. Some of them are true hardware RAID, like lats time I dealt with
 an AMCC which has PowerPC CPU on board to perform the parity computations
 and related stuff. But for today's CPUs that's not much. If you have enough
 spare cards that can be enough fine.
 One thing I also learned long time ago: make sure to have a BBU and
 that the BBU battery is charged & functional, otherwise you can be impacted
 by a significant speed hit because the card won't cache as much / caches
 differently for data integrity reasons.

 On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion <
 chris.mcquist...@gmail.com> wrote:

> I don’t think of Linux software RAID as the same as LVM but yes I
> would prefer Linux software RAID over hardware RAID because the 
> performance
> is very good and the array is portable. I had a hardware RAID card die on
> me, many years ago, and it made me realize that I was dependent on that
> single piece of hardware that the manufacturer (Adaptec) had long since
> discontinued.
>
> Sent from my iPhone
>
> On Jun 8, 2018, at 7:54 PM, Csaba Toth 
> wrote:
>
> Would you favor LVM over "hardware" (quote is half intentional)? My
> twin brother's advice is that this way I can avoid vendor lock-in. And if
> something goes south I can still migrate to anything which provides JBOD.
>
>
>
> On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion <
> chris.mcquist...@curreyingram.org> wrote:
>
>> and if you "watch cat /proc/mdstat", you can watch the progress as
>> your RAID array is built or re-built.
>>
>> *Chris McQuistion*
>>
>> Director of Information Technology
>>
>> Currey Ingram Academy
>>
>> 6544 Murray Lane, Brentwood, TN, 37027
>> 
>>
>>
>> *o* 615.507.3175   *c* 615.525.5877
>>
>> www.curreyingram.org
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:
>>
>>> Currently messing about with a software raid (md).  Found a nice
>

Re: [nlug] useful command o' the day

[Alex Smith (K4RNT)]

Am I the only one who instantly thought about ZFS?

" 'With the first link, the chain is forged. The first speech censured, the
first thought forbidden, the first freedom denied, chains us all
irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and
warning... The first time any man's freedom is trodden on, we’re all
damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG
episode "The Drumhead"
- Alex Smith
- Kent, Washington (metropolitan Seattle area)

On Thu, Jun 14, 2018 at 3:45 PM, Chris McQuistion <
chris.mcquist...@curreyingram.org> wrote:

> Always a good point.  There is NO REPLACEMENT for proper backups!
>
> *Chris McQuistion*
>
> Director of Information Technology
>
> Currey Ingram Academy
>
> 6544 Murray Lane, Brentwood, TN, 37027
> 
>
>
> *o* 615.507.3175   *c* 615.525.5877
>
> www.curreyingram.org
>
>
>
>
>
>
> On Thu, Jun 14, 2018 at 9:14 AM Tilghman Lesher 
> wrote:
>
>> All of that is moot if you're keeping offline backups (and maybe even
>> offsite backups?  Right?  Right?), as the backup ensures that even if the
>> original system becomes completely unavailable, you still have your
>> applications and data.
>>
>> On Thu, Jun 14, 2018 at 1:37 AM, Csaba Toth 
>> wrote:
>>
>>> My definition of the vendor lock-in is the same. Controller failure is
>>> much less common than than disk failure, but when it happens it can be bad.
>>> In such case moving off the data may not be easy, the controller knew how
>>> it calculated and stored the parity. It's not a rocket science and it can
>>> be forensically determined I guess, but that may require non trivial
>>> effort. I've heard of a PACS system where the controller failure was
>>> forgotten out of the contract (between the hospital and the vendor), but it
>>> happened and it was NOT pretty.
>>>
>>> With LVM it's all software, so you don't even have to move the data off,
>>> if you find any controller with JBOD capability which can show the disks
>>> again to the system.
>>>
>>> I also often come across systems which 10+ years old, still running
>>> fine, but the controllers become my first thought in my mind. The best if
>>> you have some spare one. Still SATA, but yes, PATA for example is getting
>>> really outdated.
>>>
>>>
>>> On Mon, Jun 11, 2018, 9:46 AM Tilghman Lesher 
>>> wrote:
>>>
 When I think of vendor lock-in, I generally think of the inability to
 move data off of one system.  I don't think that's really much of a
 concern, at least if you're working with business systems, and your
 hardware is not more than a few years old.  As the disks tend to fail more
 often than the controller, how you formatted and managed the disks isn't
 likely to be the main issue.

 The bigger issue that you're going to encounter is a change in hardware
 specification.  Imagine that you have a storage room full of IDE disks, and
 you needed to get information off of them, when today, the prevailing
 standard is SATA.  Or, if you're into tape backups, imagine a room full of
 backup tapes and being unable to find a working drive that takes that
 specific tape.

 On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth 
 wrote:

> True. LVM is not remotely equivalent, but can be utilized towards use
> cases of disk arrays. A well versed RAID controller makes it easy to set 
> up
> a RAID 50 for example but as you experienced, they can age and things can
> go wrong. Some of them are true hardware RAID, like lats time I dealt with
> an AMCC which has PowerPC CPU on board to perform the parity computations
> and related stuff. But for today's CPUs that's not much. If you have 
> enough
> spare cards that can be enough fine.
> One thing I also learned long time ago: make sure to have a BBU and
> that the BBU battery is charged & functional, otherwise you can be 
> impacted
> by a significant speed hit because the card won't cache as much / caches
> differently for data integrity reasons.
>
> On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion <
> chris.mcquist...@gmail.com> wrote:
>
>> I don’t think of Linux software RAID as the same as LVM but yes I
>> would prefer Linux software RAID over hardware RAID because the 
>> performance
>> is very good and the array is portable. I had a hardware RAID card die on
>> me, many years ago, and it made me realize that I was dependent on that
>> single piece of hardware that the manufacturer (Adaptec) had long since
>> discontinued.
>>
>> Sent from my iPhone
>>
>> On Jun 8, 2018, at 7:54 PM, Csaba Toth 
>> wrote:
>>
>> Would you favor LVM over "hardware" (quote is half intentional)? My
>> twin brother's advice is that this way I can avoid vendor lock-in. And if
>> something goes south I can still migrate to anything which

Re: [nlug] useful command o' the day

[Tilghman Lesher]

ZFS doesn't substitute for good backups.  If the machine suffers a
catastrophic loss, ZFS isn't going to bring your data back.  If you have a
good backup, however, you should be able to recover after a period of
downtime restoring the data.

On Thu, Jun 14, 2018 at 5:54 PM, Alex Smith (K4RNT) 
wrote:

> Am I the only one who instantly thought about ZFS?
>
> " 'With the first link, the chain is forged. The first speech censured,
> the first thought forbidden, the first freedom denied, chains us all
> irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and
> warning... The first time any man's freedom is trodden on, we’re all
> damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG
> episode "The Drumhead"
> - Alex Smith
> - Kent, Washington (metropolitan Seattle area)
>
> On Thu, Jun 14, 2018 at 3:45 PM, Chris McQuistion  curreyingram.org> wrote:
>
>> Always a good point.  There is NO REPLACEMENT for proper backups!
>>
>> *Chris McQuistion*
>>
>> Director of Information Technology
>>
>> Currey Ingram Academy
>>
>> 6544 Murray Lane, Brentwood, TN, 37027
>> 
>>
>>
>> *o* 615.507.3175   *c* 615.525.5877
>>
>> www.curreyingram.org
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 14, 2018 at 9:14 AM Tilghman Lesher 
>> wrote:
>>
>>> All of that is moot if you're keeping offline backups (and maybe even
>>> offsite backups?  Right?  Right?), as the backup ensures that even if the
>>> original system becomes completely unavailable, you still have your
>>> applications and data.
>>>
>>> On Thu, Jun 14, 2018 at 1:37 AM, Csaba Toth 
>>> wrote:
>>>
 My definition of the vendor lock-in is the same. Controller failure is
 much less common than than disk failure, but when it happens it can be bad.
 In such case moving off the data may not be easy, the controller knew how
 it calculated and stored the parity. It's not a rocket science and it can
 be forensically determined I guess, but that may require non trivial
 effort. I've heard of a PACS system where the controller failure was
 forgotten out of the contract (between the hospital and the vendor), but it
 happened and it was NOT pretty.

 With LVM it's all software, so you don't even have to move the data
 off, if you find any controller with JBOD capability which can show the
 disks again to the system.

 I also often come across systems which 10+ years old, still running
 fine, but the controllers become my first thought in my mind. The best if
 you have some spare one. Still SATA, but yes, PATA for example is getting
 really outdated.


 On Mon, Jun 11, 2018, 9:46 AM Tilghman Lesher 
 wrote:

> When I think of vendor lock-in, I generally think of the inability to
> move data off of one system.  I don't think that's really much of a
> concern, at least if you're working with business systems, and your
> hardware is not more than a few years old.  As the disks tend to fail more
> often than the controller, how you formatted and managed the disks isn't
> likely to be the main issue.
>
> The bigger issue that you're going to encounter is a change in
> hardware specification.  Imagine that you have a storage room full of IDE
> disks, and you needed to get information off of them, when today, the
> prevailing standard is SATA.  Or, if you're into tape backups, imagine a
> room full of backup tapes and being unable to find a working drive that
> takes that specific tape.
>
> On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth 
> wrote:
>
>> True. LVM is not remotely equivalent, but can be utilized towards use
>> cases of disk arrays. A well versed RAID controller makes it easy to set 
>> up
>> a RAID 50 for example but as you experienced, they can age and things can
>> go wrong. Some of them are true hardware RAID, like lats time I dealt 
>> with
>> an AMCC which has PowerPC CPU on board to perform the parity computations
>> and related stuff. But for today's CPUs that's not much. If you have 
>> enough
>> spare cards that can be enough fine.
>> One thing I also learned long time ago: make sure to have a BBU and
>> that the BBU battery is charged & functional, otherwise you can be 
>> impacted
>> by a significant speed hit because the card won't cache as much / caches
>> differently for data integrity reasons.
>>
>> On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion <
>> chris.mcquist...@gmail.com> wrote:
>>
>>> I don’t think of Linux software RAID as the same as LVM but yes I
>>> would prefer Linux software RAID over hardware RAID because the 
>>> performance
>>> is very good and the array is portable. I had a hardware RAID card die 
>>> on
>>> me, many years ago, and it made me realize that I was dependent on that
>>> sin

Re: [nlug] useful command o' the day

[Alex Smith (K4RNT)]

I'm talking about using RAID Z as an alternative to LVM. I HATE LVM.

" 'With the first link, the chain is forged. The first speech censured, the
first thought forbidden, the first freedom denied, chains us all
irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and
warning... The first time any man's freedom is trodden on, we’re all
damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG
episode "The Drumhead"
- Alex Smith
- Kent, Washington (metropolitan Seattle area)

On Fri, Jun 15, 2018 at 5:51 AM, Tilghman Lesher 
wrote:

> ZFS doesn't substitute for good backups.  If the machine suffers a
> catastrophic loss, ZFS isn't going to bring your data back.  If you have a
> good backup, however, you should be able to recover after a period of
> downtime restoring the data.
>
> On Thu, Jun 14, 2018 at 5:54 PM, Alex Smith (K4RNT) <
> shadowhun...@gmail.com> wrote:
>
>> Am I the only one who instantly thought about ZFS?
>>
>> " 'With the first link, the chain is forged. The first speech censured,
>> the first thought forbidden, the first freedom denied, chains us all
>> irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and
>> warning... The first time any man's freedom is trodden on, we’re all
>> damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG
>> episode "The Drumhead"
>> - Alex Smith
>> - Kent, Washington (metropolitan Seattle area)
>>
>> On Thu, Jun 14, 2018 at 3:45 PM, Chris McQuistion <
>> chris.mcquist...@curreyingram.org> wrote:
>>
>>> Always a good point.  There is NO REPLACEMENT for proper backups!
>>>
>>> *Chris McQuistion*
>>>
>>> Director of Information Technology
>>>
>>> Currey Ingram Academy
>>>
>>> 6544 Murray Lane, Brentwood, TN, 37027
>>> 
>>>
>>>
>>> *o* 615.507.3175   *c* 615.525.5877
>>>
>>> www.curreyingram.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 14, 2018 at 9:14 AM Tilghman Lesher 
>>> wrote:
>>>
 All of that is moot if you're keeping offline backups (and maybe even
 offsite backups?  Right?  Right?), as the backup ensures that even if the
 original system becomes completely unavailable, you still have your
 applications and data.

 On Thu, Jun 14, 2018 at 1:37 AM, Csaba Toth 
 wrote:

> My definition of the vendor lock-in is the same. Controller failure is
> much less common than than disk failure, but when it happens it can be 
> bad.
> In such case moving off the data may not be easy, the controller knew how
> it calculated and stored the parity. It's not a rocket science and it can
> be forensically determined I guess, but that may require non trivial
> effort. I've heard of a PACS system where the controller failure was
> forgotten out of the contract (between the hospital and the vendor), but 
> it
> happened and it was NOT pretty.
>
> With LVM it's all software, so you don't even have to move the data
> off, if you find any controller with JBOD capability which can show the
> disks again to the system.
>
> I also often come across systems which 10+ years old, still running
> fine, but the controllers become my first thought in my mind. The best if
> you have some spare one. Still SATA, but yes, PATA for example is getting
> really outdated.
>
>
> On Mon, Jun 11, 2018, 9:46 AM Tilghman Lesher 
> wrote:
>
>> When I think of vendor lock-in, I generally think of the inability to
>> move data off of one system.  I don't think that's really much of a
>> concern, at least if you're working with business systems, and your
>> hardware is not more than a few years old.  As the disks tend to fail 
>> more
>> often than the controller, how you formatted and managed the disks isn't
>> likely to be the main issue.
>>
>> The bigger issue that you're going to encounter is a change in
>> hardware specification.  Imagine that you have a storage room full of IDE
>> disks, and you needed to get information off of them, when today, the
>> prevailing standard is SATA.  Or, if you're into tape backups, imagine a
>> room full of backup tapes and being unable to find a working drive that
>> takes that specific tape.
>>
>> On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth 
>> wrote:
>>
>>> True. LVM is not remotely equivalent, but can be utilized towards
>>> use cases of disk arrays. A well versed RAID controller makes it easy to
>>> set up a RAID 50 for example but as you experienced, they can age and
>>> things can go wrong. Some of them are true hardware RAID, like lats 
>>> time I
>>> dealt with an AMCC which has PowerPC CPU on board to perform the parity
>>> computations and related stuff. But for today's CPUs that's not much. If
>>> you have enough spare cards that can be enough fine.
>>> One thing I also learne

Re: [nlug] useful command o' the day

[John F. Eldredge]

However, from painful first-hand experience, if hardware failure means that 
corrupted data is being passed to the backup system, and the backup system 
is then making an accurate copy of that already-corrupted data, the backup 
won't report any errors, but the backups won't be useful.


On June 14, 2018 9:14:27 AM Tilghman Lesher  wrote:
All of that is moot if you're keeping offline backups (and maybe even 
offsite backups?  Right?  Right?), as the backup ensures that even if the 
original system becomes completely unavailable, you still have your 
applications and data.



On Thu, Jun 14, 2018 at 1:37 AM, Csaba Toth  wrote:

My definition of the vendor lock-in is the same. Controller failure is much 
less common than than disk failure, but when it happens it can be bad. In 
such case moving off the data may not be easy, the controller knew how it 
calculated and stored the parity. It's not a rocket science and it can be 
forensically determined I guess, but that may require non trivial effort. 
I've heard of a PACS system where the controller failure was forgotten out 
of the contract (between the hospital and the vendor), but it happened and 
it was NOT pretty.


With LVM it's all software, so you don't even have to move the data off, if 
you find any controller with JBOD capability which can show the disks again 
to the system.



I also often come across systems which 10+ years old, still running fine, 
but the controllers become my first thought in my mind. The best if you 
have some spare one. Still SATA, but yes, PATA for example is getting 
really outdated.



On Mon, Jun 11, 2018, 9:46 AM Tilghman Lesher  wrote:
When I think of vendor lock-in, I generally think of the inability to move 
data off of one system.  I don't think that's really much of a concern, at 
least if you're working with business systems, and your hardware is not 
more than a few years old.  As the disks tend to fail more often than the 
controller, how you formatted and managed the disks isn't likely to be the 
main issue.


The bigger issue that you're going to encounter is a change in hardware 
specification.  Imagine that you have a storage room full of IDE disks, and 
you needed to get information off of them, when today, the prevailing 
standard is SATA.  Or, if you're into tape backups, imagine a room full of 
backup tapes and being unable to find a working drive that takes that 
specific tape.



On Sat, Jun 9, 2018 at 12:54 AM, Csaba Toth  wrote:

True. LVM is not remotely equivalent, but can be utilized towards use cases 
of disk arrays. A well versed RAID controller makes it easy to set up a 
RAID 50 for example but as you experienced, they can age and things can go 
wrong. Some of them are true hardware RAID, like lats time I dealt with an 
AMCC which has PowerPC CPU on board to perform the parity computations and 
related stuff. But for today's CPUs that's not much. If you have enough 
spare cards that can be enough fine.
One thing I also learned long time ago: make sure to have a BBU and that 
the BBU battery is charged & functional, otherwise you can be impacted by a 
significant speed hit because the card won't cache as much / caches 
differently for data integrity reasons.


On Fri, Jun 8, 2018 at 6:53 PM, Chris McQuistion 
 wrote:


I don’t think of Linux software RAID as the same as LVM but yes I would 
prefer Linux software RAID over hardware RAID because the performance is 
very good and the array is portable. I had a hardware RAID card die on me, 
many years ago, and it made me realize that I was dependent on that single 
piece of hardware that the manufacturer (Adaptec) had long since discontinued.



Sent from my iPhone

On Jun 8, 2018, at 7:54 PM, Csaba Toth  wrote:

Would you favor LVM over "hardware" (quote is half intentional)? My twin 
brother's advice is that this way I can avoid vendor lock-in. And if 
something goes south I can still migrate to anything which provides JBOD.




On Fri, Jun 8, 2018 at 8:00 AM, Chris McQuistion 
 wrote:


and if you "watch cat /proc/mdstat", you can watch the progress as your 
RAID array is built or re-built.


Chris McQuistion
Director of Information Technology
Currey Ingram Academy
6544 Murray Lane, Brentwood, TN, 37027
o615.507.3175c615.525.5877
www.curreyingram.org








On Fri, Jun 8, 2018 at 9:58 AM Howard White  wrote:
Currently messing about with a software raid (md).  Found a nice how-to



that included a couple of generally useful commands:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

and

cat /prod/mdstat


Enjoy.

Howard

--
--
You received this message because you are subscribed to the Google Groups 
"NLUG" group.

To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en


---
Y