[GoLugTech] 240GB is the new NAND "sweet spot"

[Bryan J Smith]

Although I have 1TB units in my notebook and desktop (and 2TB is on
the horizon), and 500GB+ tends to be the best performing thanx to lots
of DRAM, for the average consumer, 240GB is the new NAND "sweet spot."
There have been several sales as of late that have brought the 240GB
down to under $0.25/GB, and that's getting too good to ignore.
Especially with the 240GB models usually having good performance,
especially over 60-128GB and their greatly reduced DRAM.

This includes the new, consumer-oriented OCZ Arc 100, which is better
than the Crucial's consumer-oriented MX100 in Benchmarks according to
Anandtech. [1] As long as you buy two (or three if you want), you can
get them for sub-$60/each at NewEgg. [2] I tend to buy NAND devices
in bulk, as I can always use them, especially since the light, 5-7mm
devices don't even need a bay (velcro to the side of the case works
too), just data and power.

That said ... 240GB is also the minimum size I'd use for Windows in a
dual-boot. I don't recommend Windows outright, but if you
infrequently dual-boot with Windows, I've started to "chance" putting
the C: drive -- 128GiB -- on them. Why? Simple reason ...

Windows Update and most Windows software installations are written so
freak'n poorly, lots of random I/O, using a NAND device speeds them up
100x fold because of the seek difference. I cannot believe how
absolutely horrendous the I/O spread is (yes, I've run utilities to
measure it), that on the few Windows dual-boots I have, where I boot
into Windows 10% of the time, I cannot deal with the Update non-sense.

Again, I don't know if I'd do it if I ran Windows a lot. I know it
will wear out the NAND much faster than Linux. And I *never* put
*any* page file on it, I turn off indexing, I set system and user
TEMP/TMP to the platter, etc... I still have a D: drive, and I do my
best to mitigate any writing to the C: drive that is NAND --
especially those temp files.

Just like I put swap, /tmp, /var and /home (or at least the .firefox,
.chrome and other cache directories) on platter. But for infrequent
use, I'm now chancing it after seeing freak'n much it mitigates
Windows Update and other install performance. I mean, no wonder
Windows users love their NAND devices! (at least before they fail 9
months later).

I still backup the NAND regularly ... for obvious reasons. Many times
this is Linux doing a 'dd | gzip" of the C: drive to the Ext partition
in D: It's so difficult to recover Windows C:, unless you dd it.
Also use "sfdisk -d" to backup your partition table -- essential with
GPT and those UUIDs. ;)

Just wanted to mention this deal, and that now I'm putting a 240GB
into every system I have (when it's not a 1TB+), aside with every
platter. At this price point, it's hard to best.

bjs Dual-Boot Partitioning Schemes:

MBR (3 primary + 2 logical)
- 1MiB - 512MiB type 27h (Hidden OEM) "RE Tools" [X]
- 512MiB - 768MiB type OCh (FAT32) "System" partition [A]
- 768MiB - 1GiB type 83h (Ext) /boot partition
- 1GiB - final GiB [B] type 0Fh (Extended) Logical partitions
- 1GiB+1MiB [C] - 129GiB type 07h (NTFS) Windows C: Drive
- 128GiB+1MiB [C] - last full GiB [B] type 8Eh (LVM) Linux Volumes

GPT (at least 128 partitions)
- 1MiB - 1GiB type 2700h (Hidden MS-OEM) "RE Tools" [X]
- 1GiB - 1.375GiB type EF00h (ESP-FAT32) "System" partition [A]
- 1.375GiB - 1.5GiB type 0C01h (MSFTRES) Microsoft GPT [D]
- 1.5GiB - 1.75GiB type 8300h (Ext) /boot partition (distro 1)
- 1.75GiB - 2GiB type 8300h (Ext) /boot partition (distro 2)
- 2GiB - 130GiB type 07h (NTFS) Windows C: Drive [E]
- 130GiB - last full GiB [D] type 8Eh (LVM) Linux Volumes [E]

-- bjs

References:

[1] http://www.anandtech.com/show/8407/ocz-arc-100-240gb-review/
[2] http://dealnews.com/2-OCZ-Arc-100-Series-240-GB-2.5-SATA-SSDs-for-119-after-rebates-free-shipping/1412029.html

Notes:

[X] OEMs prefer this, so I just reserve the 511MiB or 1023MiB to start
the disk. If you don't want to, nix it.

[A] For MBR, if you create at least a 200GiB, FAT32 formatted
partition, the Windows 7 and 8 installers will see it as the "System"
Partition.

For GPT, you must have at least a 100GiB (260GiB if 4KiB logical
sectors, most are still 512 logical, even if 4KiB physical), FAT32
formatted partition for the EFI System Partition (ESP).

I recommend pre-creating each, with a Live USB in Linux, before
installing Windows. For GPT, I continue to prefer Rod Smith's rEFInd
boot loader in the ESP, so I don't have to mess with any other entries
in the uEFI firmware.

[B] I _always_ leave the partial 1GiB of the disk left, unused. This
prevents overwriting some meta-data that some things put at the end of
the disk. I only use the final, full GiB. In the age of NAND, not
using the whole disk is ideal as well.

[C] For MBR Logicals in Extended Partitions, start 1MiB off to align
better. Aligning on the default, next 512B (if 512B is logical, let
alone 4KiB physical) is not ideal, and 1MiB is a good alignment.

[D] Don't dual-boot with GPT without creating the 128MiB Microsoft
Reserved partition so it can file away hidden info. OEMs also use
this. I recommend doing it regardless of whether you dual-boot it or
not, especially for external drives >2TiB using GPT. Windows wants to
see it.

[E] I actually create more partitions in GPT to make things more
flexible, so I don't have to modify the disk label when the kernel is
running (which is a PITA). I mean, I can always add partitions to
LVM. But Windows C: always gets the 128GiB on the NAND, and usually
around 256-512GB on an platter.

[Kevin Korb]

Is OCZ really still in the game when it comes to SSDs? I kinda got
screwed by them on power supplies a while back.

Post by Bryan J Smith
Although I have 1TB units in my notebook and desktop (and 2TB is
on the horizon), and 500GB+ tends to be the best performing thanx
to lots of DRAM, for the average consumer, 240GB is the new NAND
"sweet spot." There have been several sales as of late that have
brought the 240GB down to under $0.25/GB, and that's getting too
good to ignore. Especially with the 240GB models usually having
good performance, especially over 60-128GB and their greatly
reduced DRAM.
This includes the new, consumer-oriented OCZ Arc 100, which is
better than the Crucial's consumer-oriented MX100 in Benchmarks
according to Anandtech. [1] As long as you buy two (or three if
you want), you can get them for sub-$60/each at NewEgg. [2] I tend
to buy NAND devices in bulk, as I can always use them, especially
since the light, 5-7mm devices don't even need a bay (velcro to the
side of the case works too), just data and power.
That said ... 240GB is also the minimum size I'd use for Windows in
a dual-boot. I don't recommend Windows outright, but if you
infrequently dual-boot with Windows, I've started to "chance"
putting the C: drive -- 128GiB -- on them. Why? Simple reason
...
Windows Update and most Windows software installations are written
so freak'n poorly, lots of random I/O, using a NAND device speeds
them up 100x fold because of the seek difference. I cannot believe
how absolutely horrendous the I/O spread is (yes, I've run
utilities to measure it), that on the few Windows dual-boots I
have, where I boot into Windows 10% of the time, I cannot deal with
the Update non-sense.
Again, I don't know if I'd do it if I ran Windows a lot. I know
it will wear out the NAND much faster than Linux. And I *never*
put *any* page file on it, I turn off indexing, I set system and
user TEMP/TMP to the platter, etc... I still have a D: drive, and
I do my best to mitigate any writing to the C: drive that is NAND
-- especially those temp files.
Just like I put swap, /tmp, /var and /home (or at least the
.firefox, .chrome and other cache directories) on platter. But for
infrequent use, I'm now chancing it after seeing freak'n much it
mitigates Windows Update and other install performance. I mean, no
wonder Windows users love their NAND devices! (at least before
they fail 9 months later).
I still backup the NAND regularly ... for obvious reasons. Many
times this is Linux doing a 'dd | gzip" of the C: drive to the Ext
partition in D: It's so difficult to recover Windows C:, unless
you dd it. Also use "sfdisk -d" to backup your partition table --
essential with GPT and those UUIDs. ;)
Just wanted to mention this deal, and that now I'm putting a 240GB
into every system I have (when it's not a 1TB+), aside with every
platter. At this price point, it's hard to best.
MBR (3 primary + 2 logical) - 1MiB - 512MiB type 27h (Hidden OEM)
"RE Tools" [X] - 512MiB - 768MiB type OCh (FAT32) "System"
partition [A] - 768MiB - 1GiB type 83h (Ext) /boot partition - 1GiB
- final GiB [B] type 0Fh (Extended) Logical partitions - 1GiB+1MiB
[C] - 129GiB type 07h (NTFS) Windows C: Drive - 128GiB+1MiB [C] -
last full GiB [B] type 8Eh (LVM) Linux Volumes
GPT (at least 128 partitions) - 1MiB - 1GiB type 2700h (Hidden
MS-OEM) "RE Tools" [X] - 1GiB - 1.375GiB type EF00h (ESP-FAT32)
"System" partition [A] - 1.375GiB - 1.5GiB type 0C01h (MSFTRES)
Microsoft GPT [D] - 1.5GiB - 1.75GiB type 8300h (Ext) /boot
partition (distro 1) - 1.75GiB - 2GiB type 8300h (Ext) /boot
Drive [E] - 130GiB - last full GiB [D] type 8Eh (LVM) Linux Volumes
[E]
-- bjs
[1] http://www.anandtech.com/show/8407/ocz-arc-100-240gb-review/
[2]
http://dealnews.com/2-OCZ-Arc-100-Series-240-GB-2.5-SATA-SSDs-for-119-

after-rebates-free-shipping/1412029.html

Post by Bryan J Smith
[X] OEMs prefer this, so I just reserve the 511MiB or 1023MiB to
start the disk. If you don't want to, nix it.
[A] For MBR, if you create at least a 200GiB, FAT32 formatted
partition, the Windows 7 and 8 installers will see it as the
"System" Partition.
For GPT, you must have at least a 100GiB (260GiB if 4KiB logical
sectors, most are still 512 logical, even if 4KiB physical), FAT32
formatted partition for the EFI System Partition (ESP).
I recommend pre-creating each, with a Live USB in Linux, before
installing Windows. For GPT, I continue to prefer Rod Smith's
rEFInd boot loader in the ESP, so I don't have to mess with any
other entries in the uEFI firmware.
[B] I _always_ leave the partial 1GiB of the disk left, unused.
This prevents overwriting some meta-data that some things put at
the end of the disk. I only use the final, full GiB. In the age
of NAND, not using the whole disk is ideal as well.
[C] For MBR Logicals in Extended Partitions, start 1MiB off to
align better. Aligning on the default, next 512B (if 512B is
logical, let alone 4KiB physical) is not ideal, and 1MiB is a good
alignment.
[D] Don't dual-boot with GPT without creating the 128MiB Microsoft
Reserved partition so it can file away hidden info. OEMs also use
this. I recommend doing it regardless of whether you dual-boot it
or not, especially for external drives >2TiB using GPT. Windows
wants to see it.
[E] I actually create more partitions in GPT to make things more
flexible, so I don't have to modify the disk label when the kernel
is running (which is a PITA). I mean, I can always add partitions
to LVM. But Windows C: always gets the 128GiB on the NAND, and
usually around 256-512GB on an platter.

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Kevin Korb]

Well, I just took a look and I guess they are. They used to make the
best thumb drives but then fell behind then quit making them. They
also used to make really good power supplies then they had bad caps
and abandoned the market while unloading the warranties to a 3rd
party. But I guess they trimmed down to just an SSD company.

Post by Kevin Korb
Is OCZ really still in the game when it comes to SSDs? I kinda
got screwed by them on power supplies a while back.

Post by Bryan J Smith
Although I have 1TB units in my notebook and desktop (and 2TB is
on the horizon), and 500GB+ tends to be the best performing
thanx to lots of DRAM, for the average consumer, 240GB is the new
NAND "sweet spot." There have been several sales as of late that
have brought the 240GB down to under $0.25/GB, and that's getting
too good to ignore. Especially with the 240GB models usually
having good performance, especially over 60-128GB and their
greatly reduced DRAM.
This includes the new, consumer-oriented OCZ Arc 100, which is
better than the Crucial's consumer-oriented MX100 in Benchmarks
according to Anandtech. [1] As long as you buy two (or three if
you want), you can get them for sub-$60/each at NewEgg. [2] I
tend to buy NAND devices in bulk, as I can always use them,
especially since the light, 5-7mm devices don't even need a bay
(velcro to the side of the case works too), just data and power.
That said ... 240GB is also the minimum size I'd use for Windows
in a dual-boot. I don't recommend Windows outright, but if you
infrequently dual-boot with Windows, I've started to "chance"
putting the C: drive -- 128GiB -- on them. Why? Simple reason
...
Windows Update and most Windows software installations are
written so freak'n poorly, lots of random I/O, using a NAND
device speeds them up 100x fold because of the seek difference.
I cannot believe how absolutely horrendous the I/O spread is
(yes, I've run utilities to measure it), that on the few Windows
dual-boots I have, where I boot into Windows 10% of the time, I
cannot deal with the Update non-sense.
Again, I don't know if I'd do it if I ran Windows a lot. I know
it will wear out the NAND much faster than Linux. And I *never*
put *any* page file on it, I turn off indexing, I set system and
user TEMP/TMP to the platter, etc... I still have a D: drive,
and I do my best to mitigate any writing to the C: drive that is
NAND -- especially those temp files.
Just like I put swap, /tmp, /var and /home (or at least the
.firefox, .chrome and other cache directories) on platter. But
for infrequent use, I'm now chancing it after seeing freak'n much
it mitigates Windows Update and other install performance. I
mean, no wonder Windows users love their NAND devices! (at least
before they fail 9 months later).
I still backup the NAND regularly ... for obvious reasons. Many
times this is Linux doing a 'dd | gzip" of the C: drive to the
Ext partition in D: It's so difficult to recover Windows C:,
unless you dd it. Also use "sfdisk -d" to backup your partition
table -- essential with GPT and those UUIDs. ;)
Just wanted to mention this deal, and that now I'm putting a
240GB into every system I have (when it's not a 1TB+), aside with
every platter. At this price point, it's hard to best.
MBR (3 primary + 2 logical) - 1MiB - 512MiB type 27h (Hidden
OEM) "RE Tools" [X] - 512MiB - 768MiB type OCh (FAT32) "System"
partition [A] - 768MiB - 1GiB type 83h (Ext) /boot partition -
1GiB - final GiB [B] type 0Fh (Extended) Logical partitions -
1GiB+1MiB [C] - 129GiB type 07h (NTFS) Windows C: Drive -
128GiB+1MiB [C] - last full GiB [B] type 8Eh (LVM) Linux Volumes
GPT (at least 128 partitions) - 1MiB - 1GiB type 2700h (Hidden
MS-OEM) "RE Tools" [X] - 1GiB - 1.375GiB type EF00h (ESP-FAT32)
"System" partition [A] - 1.375GiB - 1.5GiB type 0C01h (MSFTRES)
Microsoft GPT [D] - 1.5GiB - 1.75GiB type 8300h (Ext) /boot
partition (distro 1) - 1.75GiB - 2GiB type 8300h (Ext) /boot
Drive [E] - 130GiB - last full GiB [D] type 8Eh (LVM) Linux
Volumes [E]
-- bjs
[1] http://www.anandtech.com/show/8407/ocz-arc-100-240gb-review/
[2]
http://dealnews.com/2-OCZ-Arc-100-Series-240-GB-2.5-SATA-SSDs-for-119

- -
after-rebates-free-shipping/1412029.html

Post by Kevin Korb

Post by Bryan J Smith
[X] OEMs prefer this, so I just reserve the 511MiB or 1023MiB to
start the disk. If you don't want to, nix it.
[A] For MBR, if you create at least a 200GiB, FAT32 formatted
partition, the Windows 7 and 8 installers will see it as the
"System" Partition.
For GPT, you must have at least a 100GiB (260GiB if 4KiB logical
sectors, most are still 512 logical, even if 4KiB physical),
FAT32 formatted partition for the EFI System Partition (ESP).
I recommend pre-creating each, with a Live USB in Linux, before
installing Windows. For GPT, I continue to prefer Rod Smith's
rEFInd boot loader in the ESP, so I don't have to mess with any
other entries in the uEFI firmware.
[B] I _always_ leave the partial 1GiB of the disk left, unused.
This prevents overwriting some meta-data that some things put at
the end of the disk. I only use the final, full GiB. In the
age of NAND, not using the whole disk is ideal as well.
[C] For MBR Logicals in Extended Partitions, start 1MiB off to
align better. Aligning on the default, next 512B (if 512B is
logical, let alone 4KiB physical) is not ideal, and 1MiB is a
good alignment.
[D] Don't dual-boot with GPT without creating the 128MiB
Microsoft Reserved partition so it can file away hidden info.
OEMs also use this. I recommend doing it regardless of whether
you dual-boot it or not, especially for external drives >2TiB
using GPT. Windows wants to see it.
[E] I actually create more partitions in GPT to make things more
flexible, so I don't have to modify the disk label when the
kernel is running (which is a PITA). I mean, I can always add
partitions to LVM. But Windows C: always gets the 128GiB on the
NAND, and usually around 256-512GB on an platter.

_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Kevin Korb]

[Bryan J Smith]

Post by Kevin Korb
Is OCZ really still in the game when it comes to SSDs?

Yes. They have a full line of different products.

E.g., the OCZ Arc 100 is the lower-end consumer product, much like the
Crucial MX100.

Post by Kevin Korb
I kinda got screwed by them on power supplies a while back.

Brand name doesn't mean squat these days, as OEM's switch ODM's
regularly, including for wildly different products.

Ergo ...

Post by Kevin Korb
Well, I just took a look and I guess they are. They used to make the
best thumb drives but then fell behind then quit making them. They
also used to make really good power supplies then they had bad caps
and abandoned the market while unloading the warranties to a 3rd
party. But I guess they trimmed down to just an SSD company.

Any time you guys want to pool some money and start an OEM ... say
"GoLitt" ... just let me know and we'll fly to Taiwan to meet with
some ODMs. ;)

The GoLitt UberSSD ... a 10-fold speed up in surfing Troubleshooters.COM!

[Bryan J Smith]

Post by Bryan J Smith
...
the OCZ Arc 100 is the lower-end consumer product, much like the
Crucial MX100.

So ... it appears the OCZ Trion 100 series is using the Toshiba 19nm
128Gb NAND devices -- TLC (3-bit MLC) -- and AnandTech did a review.
[1]

There wasn't any commentary about DRAM buffer/cache on-device. I can
only assume that might be one way they are saving money.

The Trion 100 modles are at the middle or the pack -- at best -- but
even worse their their own Arc 100 at times, as well as the Crucial
BX/MX products too.

So ... brings me back to my prior comments ...

If you have the money, look at the TLC (3-bit MLC) options (EVO) from
Samsung or, better yet for longevity, even the MLC (2-bit MLC) options
(EVO).

But when these things are 25, 33 or even 40% cheaper after rebate,
especially in the 240-256GB range where it's the "sweet spot," really
look at these for your root (/) and static files, while pairing them
with a traditional hard drive. The latency of reads from a NAND --
even a slower design -- is still worth it over a hard drive.

Sandisk and Toshiba just seem to have trouble keeping up with Samsung
on performance, which isn't surprising given Samsung is an OEM who is
their own ODM. At the same time, Samsung has totally screwed up
firmware updates and caused data loss, so they've had their issues
too.

I purposely hold back on upgrading firmware, unless their is a known
issue I have to be worried about.

-- bjs

[1] http://www.anandtech.com/show/9408/ocz-trion-100-240gb-480gb-960gb-review

[Bryan J Smith]

Although they only reviewed the 480 and 960GB, these guys had another
viewpoint. I like how they harped on longevity, which is the serious
concern with TLC (3-bit MLC). [1]

I.e., OCZ-Toshiba basically makes 1.5% of the NAND as SLC (1-bit), so
1.8GB in 120GB, 3.6GB in 240GB, etc...

How this holds-up long-term ... is anyone's guess. But it does reduce
the for RAM and other things, to mitigate the limited lifespan of NAND
TLC.

Especially for Windows where it just writes little bits to blocks
over, and over, and over, instead of coalescing writes correctly. So
that 100TB alleged "lifespan" doesn't amount to much when you're only
writing out little bits, then again, then again, to the same blocks.

-- bjs

[1] http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/69761-ocz-trion-100-480gb-960gb-ssd-review-11.html

Post by Bryan J Smith

Post by Bryan J Smith
...
the OCZ Arc 100 is the lower-end consumer product, much like the
Crucial MX100.

So ... it appears the OCZ Trion 100 series is using the Toshiba 19nm
128Gb NAND devices -- TLC (3-bit MLC) -- and AnandTech did a review.
[1]
There wasn't any commentary about DRAM buffer/cache on-device. I can
only assume that might be one way they are saving money.
The Trion 100 modles are at the middle or the pack -- at best -- but
even worse their their own Arc 100 at times, as well as the Crucial
BX/MX products too.
So ... brings me back to my prior comments ...
If you have the money, look at the TLC (3-bit MLC) options (EVO) from
Samsung or, better yet for longevity, even the MLC (2-bit MLC) options
(EVO).
But when these things are 25, 33 or even 40% cheaper after rebate,
especially in the 240-256GB range where it's the "sweet spot," really
look at these for your root (/) and static files, while pairing them
with a traditional hard drive. The latency of reads from a NAND --
even a slower design -- is still worth it over a hard drive.
Sandisk and Toshiba just seem to have trouble keeping up with Samsung
on performance, which isn't surprising given Samsung is an OEM who is
their own ODM. At the same time, Samsung has totally screwed up
firmware updates and caused data loss, so they've had their issues
too.
I purposely hold back on upgrading firmware, unless their is a known
issue I have to be worried about.
-- bjs
[1] http://www.anandtech.com/show/9408/ocz-trion-100-240gb-480gb-960gb-review
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith

[Steve Litt]

On Thu, 13 Aug 2015 13:55:03 -0400

Post by Bryan J Smith
So ... brings me back to my prior comments ...
If you have the money, look at the TLC (3-bit MLC) options (EVO) from
Samsung or, better yet for longevity, even the MLC (2-bit MLC) options
(EVO).
But when these things are 25, 33 or even 40% cheaper after rebate,
especially in the 240-256GB range where it's the "sweet spot," really
look at these for your root (/) and static files, while pairing them
with a traditional hard drive. The latency of reads from a NAND --
even a slower design -- is still worth it over a hard drive.

Hi Bryan,

This has been a long thread, but if I remember correctly, you felt that
even with heavy writes, current SSDs would last a long time and there
was no reason to confine them to read-only duty (/usr, /usr/local, etc).

If that's the case, wouldn't the optimal configuration be SSD for / and
if you'd like partitions of the SSD for /var and whatever else, and use
a spinning disk specifically for /home, where file usage could easily
quickly outspace 256GB?

Or, if you're using LVM, same thing: Make sure all of /home's space
comes from spinning disks, and all of everything else comes from the
SSD?

I've never heard of a Linux OS that could outgrow 256GB, as long as
data was kept elsewhere.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

[Bryan J Smith]

Post by Steve Litt
Hi Bryan,
This has been a long thread, but if I remember correctly, you felt that
even with heavy writes, current SSDs would last a long time and there
was no reason to confine them to read-only duty (/usr, /usr/local, etc).

No, they still have issues, and longevity is actually getting worse
with TLC (3-bit MLC). Despite improvements in "rotation," there are
still issues.

That said ...

If you change out your NAND every 18 months, you might be okay. Right
now I'm "chancing" it with Windows C: (128GiB) on my 1TB Samsung EVO
840. But C: is only 1/8th of the device. ;)

The reason? Windows f'ing Update is written like a 2 year-old has a
temper tantrum. It literally makes the absolute worst use of a disk
when it comes to sporadic writing and temporary locations.

Hence why NAND speeds up writes to the point that Windows Update runs
20x faster. Makes far, far less different than for Apt or Yum. Hence
why people think NAND is so fast ... Windows' horrendous, standard
operations. ;)

Post by Steve Litt
If that's the case, wouldn't the optimal configuration be SSD for / and
if you'd like partitions of the SSD for /var and whatever else, and use
a spinning disk specifically for /home, where file usage could easily
quickly outspace 256GB?

I'll _never_ use NAND for SWAP, /tmp or /var, not even MLC (2-bit MLC)
and I'd be even hard pressed for SLC (1-bit). There are just too many
little writes to use NAND blocks (typically 32-512KiB) effectively.

Keep these numbers in mind ...
- 1,000 writes typically invalidate a SLC (1-bit)
- 100 writes typically invalidate a MLC (2-bit)
- 10 writes typically invalidate a TLC (aka 3-bit MLC)

Rotation only goes so far. ;)

At most ... if I'm SSD-only, I'd use tmpfs (RAM) for /tmp, and put
/var on the NAND, with tmpfs (RAM) for /var/tmp.

As far as /home[/local] (/exports/local), I don't recommend NAND for
it either ... _unless_ you create a tmpfs ramdisk and point any
"cache" to it (e.g., chrome, firefox, etc...). But one can do that
with a spinning disk too, and get a 10x boost -- without a NAND. ;)

I have /home/static (/exports/static) for "static" data. I'll symlink
into it from other areas. That way I can have larger spindle, and
then select NAND usage.

E.g.,
/home/static/dist (software distribution)
/home/static/media (pictures/video)
/home/static/user (free for all, chmod 1777)

Post by Steve Litt
Or, if you're using LVM, same thing: Make sure all of /home's space
comes from spinning disks, and all of everything else comes from the
SSD?
I've never heard of a Linux OS that could outgrow 256GB, as long as
data was kept elsewhere.

I use a 16GiB root (/), sometimes 32GiB if there are going to be a lot
of binaries.

-- bjs

[Steve Litt]

On Thu, 13 Aug 2015 15:33:33 -0400

Post by Bryan J Smith

Post by Steve Litt
Hi Bryan,
This has been a long thread, but if I remember correctly, you felt
that even with heavy writes, current SSDs would last a long time
and there was no reason to confine them to read-only duty
(/usr, /usr/local, etc).

No, they still have issues, and longevity is actually getting worse
with TLC (3-bit MLC). Despite improvements in "rotation," there are
still issues.
That said ...

Cool. I'll just keep on using SSD for /,
have /usr, /bin, /sbin, /usr/sbin, and /usr/local and /opt on SSD, and
use spinning disks for everything else. It's been working out great for
me so far.

Thanks,

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

[Steve Litt]

On Thu, 30 Jul 2015 19:55:10 -0400

Post by Bryan J Smith
Although I have 1TB units in my notebook and desktop (and 2TB is on
the horizon), and 500GB+ tends to be the best performing thanx to lots
of DRAM, for the average consumer, 240GB is the new NAND "sweet spot."

When shopping for components for my current daily driver about a year
ago, I decided to have my root partition on an SSD, and at the time was
256GB. So here's what I did:

sda 8:0 0 223.6G 0 disk
└─sda1 8:1 0 223.6G 0 part /
sdb 8:16 0 2.7T 0 disk
├─sdb1 8:17 0 83.8G 0 part /home
├─sdb2 8:18 0 58.6G 0 part /s
├─sdb3 8:19 0 58.6G 0 part /d
├─sdb4 8:20 0 58.6G 0 part /inst
├─sdb5 8:21 0 19.5G 0 part /classic/a
├─sdb6 8:22 0 19.5G 0 part /classic/b
├─sdb7 8:23 0 19.5G 0 part /classic/c
├─sdb8 8:24 0 117.2G 0 part /home/slitt/mail/Maildir
└─sdb9 8:25 0 2.3T 0 part /scratch
sdc 8:32 0 698.7G 0 disk
├─sdc1 8:33 0 2.8G 0 part /boot
├─sdc2 8:34 0 1K 0 part
├─sdc5 8:37 0 44.7G 0 part [SWAP]
├─sdc6 8:38 0 46.6G 0 part /var
├─sdc7 8:39 0 953M 0 part /tmp
└─sdc8 8:40 0 953M 0 part /run

For now, I'm using the SSD for tasks that are mostly reading, which
means /usr and /etc for sure. The only thing slowing this computer is
that /dev/sdb is a Western Digital Green, which means a lot of latency.
I'm going to replace it with a Western Digital Black, and use the Green
for very long term data and spare space.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Kevin Korb]

lol, You are talking pasting info on a system with 16 partitions in a
thread with both Brian Smith and me. Get ready for a lecture on the
use of lvm.

Anyways, you should not have more than #disks+1 partitions on a
post-~2005 Linux computer. Brian will probably pick an earlier date
as I was a bit stubborn.

Also, why is your / and /boot on different disks?!

Also, why is your /boot 2.8GB?! WTF do you have in there? Every
kernel since 1996?

Also, isn't /run supposed to be tmpfs?

On Thu, 30 Jul 2015 19:55:10 -0400 Bryan J Smith

Post by Bryan J Smith
Although I have 1TB units in my notebook and desktop (and 2TB is
on the horizon), and 500GB+ tends to be the best performing thanx
to lots of DRAM, for the average consumer, 240GB is the new NAND
"sweet spot."

When shopping for components for my current daily driver about a
year ago, I decided to have my root partition on an SSD, and at the
sda 8:0 0 223.6G 0 disk └─sda1 8:1 0 223.6G 0 part
/ sdb 8:16 0 2.7T 0 disk ├─sdb1 8:17 0 83.8G 0 part
/home ├─sdb2 8:18 0 58.6G 0 part /s ├─sdb3 8:19 0 58.6G
0 part /d ├─sdb4 8:20 0 58.6G 0 part /inst ├─sdb5 8:21 0
19.5G 0 part /classic/a ├─sdb6 8:22 0 19.5G 0 part
/classic/b ├─sdb7 8:23 0 19.5G 0 part /classic/c ├─sdb8
8:24 0 117.2G 0 part /home/slitt/mail/Maildir └─sdb9 8:25 0
2.3T 0 part /scratch sdc 8:32 0 698.7G 0 disk ├─sdc1
8:33 0 2.8G 0 part /boot ├─sdc2 8:34 0 1K 0 part
├─sdc5 8:37 0 44.7G 0 part [SWAP] ├─sdc6 8:38 0 46.6G 0
part /var ├─sdc7 8:39 0 953M 0 part /tmp └─sdc8 8:40 0
953M 0 part /run
For now, I'm using the SSD for tasks that are mostly reading,
which means /usr and /etc for sure. The only thing slowing this
computer is that /dev/sdb is a Western Digital Green, which means a
lot of latency. I'm going to replace it with a Western Digital
Black, and use the Green for very long term data and spare space.
SteveT
Steve Litt July 2015 featured book: Rapid Learning for the 21st
Century http://www.troubleshooters.com/rl21
_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Kevin Korb]

Oops, extra word in my first sentence.

Also, if doing RAID it is acceptable to have #disks+2 partitions in a
system. Note that I am being generous here. I know people who insist
that only the boot disk be partitioned. I happen to disagree. I
insist that there always be a partition table on a disk so that it
doesn't look like a blank/unused disk to a n00b. I can sacrifice a
few KB of disk space for a simple notation of "hey, this disk has data
on it!".

Post by Kevin Korb
lol, You are talking pasting info on a system with 16 partitions in
a thread with both Brian Smith and me. Get ready for a lecture on
the use of lvm.
Anyways, you should not have more than #disks+1 partitions on a
post-~2005 Linux computer. Brian will probably pick an earlier
date as I was a bit stubborn.
Also, why is your / and /boot on different disks?!
Also, why is your /boot 2.8GB?! WTF do you have in there? Every
kernel since 1996?
Also, isn't /run supposed to be tmpfs?

On Thu, 30 Jul 2015 19:55:10 -0400 Bryan J Smith

Post by Bryan J Smith
Although I have 1TB units in my notebook and desktop (and 2TB
is on the horizon), and 500GB+ tends to be the best performing
thanx to lots of DRAM, for the average consumer, 240GB is the
new NAND "sweet spot."

When shopping for components for my current daily driver about a
year ago, I decided to have my root partition on an SSD, and at
sda 8:0 0 223.6G 0 disk └─sda1 8:1 0 223.6G 0
part / sdb 8:16 0 2.7T 0 disk ├─sdb1 8:17 0 83.8G
0 part /home ├─sdb2 8:18 0 58.6G 0 part /s ├─sdb3 8:19
0 58.6G 0 part /d ├─sdb4 8:20 0 58.6G 0 part /inst ├─sdb5
8:21 0 19.5G 0 part /classic/a ├─sdb6 8:22 0 19.5G 0
part /classic/b ├─sdb7 8:23 0 19.5G 0 part /classic/c
├─sdb8 8:24 0 117.2G 0 part /home/slitt/mail/Maildir └─sdb9
8:25 0 2.3T 0 part /scratch sdc 8:32 0 698.7G 0 disk
├─sdc1 8:33 0 2.8G 0 part /boot ├─sdc2 8:34 0 1K 0
part ├─sdc5 8:37 0 44.7G 0 part [SWAP] ├─sdc6 8:38 0
46.6G 0 part /var ├─sdc7 8:39 0 953M 0 part /tmp └─sdc8
8:40 0 953M 0 part /run
For now, I'm using the SSD for tasks that are mostly reading,
which means /usr and /etc for sure. The only thing slowing this
computer is that /dev/sdb is a Western Digital Green, which means
a lot of latency. I'm going to replace it with a Western Digital
Black, and use the Green for very long term data and spare
space.
SteveT
Steve Litt July 2015 featured book: Rapid Learning for the 21st
Century http://www.troubleshooters.com/rl21
_______________________________________________ Tech mailing list

_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Steve Litt]

On Thu, 30 Jul 2015 20:32:27 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
lol, You are talking pasting info on a system with 16 partitions in a
thread with both Brian Smith and me. Get ready for a lecture on the
use of lvm.

I like to minimize my layering. And this computer works fast and
perfectly.

Anyways, you should not have more than #disks+1 partitions on a
post-~2005 Linux computer. Brian will probably pick an earlier date
as I was a bit stubborn.

Hey, this works perfectly for me.

Also, why is your / and /boot on different disks?!

I'll admit that's pretty bizarre. I promise I'll never do that again.

Also, why is your /boot 2.8GB?! WTF do you have in there? Every
kernel since 1996?

***@mydesq2:~$ df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdc1 2882592 88988 2647172 4% /boot
***@mydesq2:~$ df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 2.8G 87M 2.6G 4% /boot
***@mydesq2:~$ du -h /boot
du: cannot read directory `/boot/lost+found': Permission denied
16K /boot/lost+found
652K /boot/grub/locale
2.4M /boot/grub
19M /boot
***@mydesq2:~$

I like to have a little extra room :-)

Also, isn't /run supposed to be tmpfs?

Well, IIRC /run is tmpfs on Gentoo, Funtoo and Plop. A little reading
at
https://wiki.debian.org/ReleaseGoals/RunDirectory#Why_do_we_need_.2Frun.3F
indicates to me that yes, it should be a tmpfs filesystem.

On my computer, things are a little different:

***@mydesq2:~$ mount | grep run

tmpfs on /run type tmpfs
(rw,nosuid,noexec,relatime,size=1563852k,mode=755)

tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k)

tmpfs on /run/shm type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=12502400k)

/dev/sdc8 on /run type ext4
(rw,relatime,user_xattr,barrier=1,data=ordered)

tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k)

tmpfs on /run/shm type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=12502400k)

***@mydesq2:~$

I know what I was thinking at the time: I didn't want a bunch of
transient PIDs being written and overwritten to my SSD. Having never
installed Plop, Gentoo or Funtoo, I wasn't fully aware of tmpfs
filesystems. Surprisingly, I'm not having many ghosts of boot sessions
past, and this computer seems fairly fast.

What really raises the humor level is that the purpose of the
tmpfs /run is for the initramfs to store stuff before the root
partition is mounted. So theoretically my computer shouldn't boot.

I have a feeling that because I boot very simply up to CLI, and I need
no LVM drivers or software, that nothing needing what would have been
stored in /run is needed during later bootup and normal operation.

The next time I do an especially good backup, complete with a Blu-Ray
of the backup in my safe deposit box, I'll fix that. But knowing my
luck, it will break everything, so I'll need to System Rescue CD in and
put it back to /dev/sdc8 :-)

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Kevin Korb]

Post by Steve Litt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
lol, You are talking pasting info on a system with 16 partitions
in a thread with both Brian Smith and me. Get ready for a
lecture on the use of lvm.

I like to minimize my layering. And this computer works fast and
perfectly.

Open source software is the layering of of open standards. If you
want to continue layering 1980s proprietary MSDOS technology on top of
1980s MSDOS technology then you can go fork yourself into the dredges
of moron who encountered a Slackware boot floppy and thought "oooh, a
better cmd.com and I refuse to ever even consider any other possible
improvement!".

Post by Steve Litt

Anyways, you should not have more than #disks+1 partitions on a
post-~2005 Linux computer. Brian will probably pick an earlier
date as I was a bit stubborn.

Hey, this works perfectly for me.'

Yeah, I still have a MS DOS 6.2 system that "works perfectly". I keep
it around for the games that were only designed for it.

But it really doesn't matter. I use MS DOS because it works for those
games. I would never use it for anything useful. In fact, I only
ever use it as a RAM disk.

Post by Steve Litt

Also, why is your / and /boot on different disks?!

I'll admit that's pretty bizarre. I promise I'll never do that
again.

Also, why is your /boot 2.8GB?! WTF do you have in there?
Every kernel since 1996?

Use% Mounted on /dev/sdc1 2882592 88988 2647172 4%
Use% Mounted on /dev/sdc1 2.8G 87M 2.6G 4% /boot
`/boot/lost+found': Permission denied 16K /boot/lost+found 652K
I like to have a little extra room :-)

K, I can understand room to grow. But you have allocated enough room
to accomidate everything I have done (in the boot context) since I
first encountered.

Note, that I have also allocated many more MB than needed to /boot. I
like to move /etc/lvm/archive and /etc/lvm/backup into /boot/lvm. I
have never personally encountered such a disaster but I have lurked in
#lvm2 and I have seen many unfortunate souls groking through a dump of
/dev/sda trying to find some hint of a sane LVM2 config file.

Post by Steve Litt

Also, isn't /run supposed to be tmpfs?

Well, IIRC /run is tmpfs on Gentoo, Funtoo and Plop. A little
reading at
https://wiki.debian.org/ReleaseGoals/RunDirectory#Why_do_we_need_.2Fru

n.3F
indicates to me that yes, it should be a tmpfs filesystem.

Post by Steve Litt
tmpfs on /run type tmpfs
(rw,nosuid,noexec,relatime,size=1563852k,mode=755)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=12502400k)
/dev/sdc8 on /run type ext4
(rw,relatime,user_xattr,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=12502400k)
I know what I was thinking at the time: I didn't want a bunch of
transient PIDs being written and overwritten to my SSD. Having
never installed Plop, Gentoo or Funtoo, I wasn't fully aware of
tmpfs filesystems. Surprisingly, I'm not having many ghosts of boot
sessions past, and this computer seems fairly fast.
What really raises the humor level is that the purpose of the tmpfs
/run is for the initramfs to store stuff before the root partition
is mounted. So theoretically my computer shouldn't boot.
I have a feeling that because I boot very simply up to CLI, and I
need no LVM drivers or software, that nothing needing what would
have been stored in /run is needed during later bootup and normal
operation.
The next time I do an especially good backup, complete with a
Blu-Ray of the backup in my safe deposit box, I'll fix that. But
knowing my luck, it will break everything, so I'll need to System
Rescue CD in and put it back to /dev/sdc8 :-)
SteveT
Steve Litt July 2015 featured book: Rapid Learning for the 21st
Century http://www.troubleshooters.com/rl21
_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Steve Litt]

On Fri, 31 Jul 2015 00:54:46 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Steve Litt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
lol, You are talking pasting info on a system with 16 partitions
in a thread with both Brian Smith and me. Get ready for a
lecture on the use of lvm.

I like to minimize my layering. And this computer works fast and
perfectly.

Open source software is the layering of of open standards. If you
want to continue layering 1980s proprietary MSDOS technology on top of
1980s MSDOS technology

File naming and directory organization != technology.

then you can go fork yourself into the dredges
of moron who encountered a Slackware boot floppy and thought "oooh, a
better cmd.com and I refuse to ever even consider any other possible
improvement!".

Post by Steve Litt

Anyways, you should not have more than #disks+1 partitions on a
post-~2005 Linux computer. Brian will probably pick an earlier
date as I was a bit stubborn.

Hey, this works perfectly for me.'

Yeah, I still have a MS DOS 6.2 system that "works perfectly". I keep
it around for the games that were only designed for it.
But it really doesn't matter. I use MS DOS because it works for those
games. I would never use it for anything useful. In fact, I only
ever use it as a RAM disk.

This is exactly my point. MS-DOS was so good I'd use it today if it had:

* Multi-user and multitasking
* Real shellscripting
* 64 bits
* Signals
* FIFOs
* Sockets
* AWK, Python, Lua, Java, C/C++ interpreters and compilers
* Excellent GUI environment like Openbox + dmenu
* A modular architecture I could take apart if needed
* A license saying I can change it, copy it, and give it to 1000 of my
closest friends.

[snip]

Note, that I have also allocated many more MB than needed to /boot. I
like to move /etc/lvm/archive and /etc/lvm/backup into /boot/lvm. I
have never personally encountered such a disaster but I have lurked in
#lvm2 and I have seen many unfortunate souls groking through a dump of
/dev/sda trying to find some hint of a sane LVM2 config file.

Yet another problem I'll never have because I don't use LVM.

Listen, some day my life might change to the point where moving disk
capacity around becomes a common occurrance. Or I might decide that my
easiest avenue to disk encryption is LVM. But until then, other than
style points, I lose nothing by foregoing that extra level of
abstraction, and the potential problems that any level of abstraction
brings with it.


SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Shawn McMahon]

You also give up all the advantages of that level of abstraction, which
makes sense only if you believe there were no problems it was created to
solve or that it's untested new technology that hasn't had sufficient time
to work out the bugs that come along with those advantages. It's nearly as
old as Linux.

Post by Steve Litt
On Fri, 31 Jul 2015 00:54:46 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Steve Litt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
lol, You are talking pasting info on a system with 16 partitions
in a thread with both Brian Smith and me. Get ready for a
lecture on the use of lvm.

I like to minimize my layering. And this computer works fast and
perfectly.

Open source software is the layering of of open standards. If you
want to continue layering 1980s proprietary MSDOS technology on top of
1980s MSDOS technology

File naming and directory organization != technology.

then you can go fork yourself into the dredges
of moron who encountered a Slackware boot floppy and thought "oooh, a
better cmd.com and I refuse to ever even consider any other possible
improvement!".

Post by Steve Litt

Anyways, you should not have more than #disks+1 partitions on a
post-~2005 Linux computer. Brian will probably pick an earlier
date as I was a bit stubborn.

Hey, this works perfectly for me.'

Yeah, I still have a MS DOS 6.2 system that "works perfectly". I keep
it around for the games that were only designed for it.
But it really doesn't matter. I use MS DOS because it works for those
games. I would never use it for anything useful. In fact, I only
ever use it as a RAM disk.

* Multi-user and multitasking
* Real shellscripting
* 64 bits
* Signals
* FIFOs
* Sockets
* AWK, Python, Lua, Java, C/C++ interpreters and compilers
* Excellent GUI environment like Openbox + dmenu
* A modular architecture I could take apart if needed
* A license saying I can change it, copy it, and give it to 1000 of my
closest friends.
[snip]

Note, that I have also allocated many more MB than needed to /boot. I
like to move /etc/lvm/archive and /etc/lvm/backup into /boot/lvm. I
have never personally encountered such a disaster but I have lurked in
#lvm2 and I have seen many unfortunate souls groking through a dump of
/dev/sda trying to find some hint of a sane LVM2 config file.

Yet another problem I'll never have because I don't use LVM.
Listen, some day my life might change to the point where moving disk
capacity around becomes a common occurrance. Or I might decide that my
easiest avenue to disk encryption is LVM. But until then, other than
style points, I lose nothing by foregoing that extra level of
abstraction, and the potential problems that any level of abstraction
brings with it.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Bryan J Smith]

Post by Shawn McMahon
You also give up all the advantages of that level of abstraction, which
makes sense only if you believe there were no problems it was created to
solve or that it's untested new technology that hasn't had sufficient time
to work out the bugs that come along with those advantages. It's nearly as
old as Linux.

And the Device Mapper generation of LVM, called version 2 (DM-LVM2),
in kernel 2.6+ has *0* overhead. Whether a "block device" is a
Logical Volume (LV), partition, whole disk or other organization --
including striping logical volumes -- it is addressed and accessed by
the kernel's Device Mapper facility the exact _same_.

Only when LVM "features" like mirroring (which I wouldn't use -- only
the newer MD-based implements), copy-on-write (including writeable
snapshots, something LVM[v1] couldn't do), etc... will add overhead.
Most of these are general Device Mapper capabilities that LVM
contains, and contains very well and ... more importantly ... _safer_
than other "containers."

And it's a virtual no-brainer when it comes to encrypted file systems.

But, while I agree with both the Korbinator and yourself, I do note
the following cases where LVM may not be an option.

1) The sysadmin doesn't know it well, or
2) The NAND device doesn't support discard/trim properly

I've long recognized #1 as a problem. The last thing I want is
someone with LVM who doesn't understand it. You don't have to be a
Device Mapper internals guru, and know how to recreate things with
"dmsetup," to be an LVM expert. Getting people to understand the
PV->VG-LV and, more importantly, PE~LE (Extents) aspects, plus common
operations like the [vg|lv]extend and the very pvmove commands, are
key.

I also ran into a case with #2 a long time ago. So with those units,
I will often create a root (/) on NAND with _no_ /boot or LVM. But
those days are largely long gone now.

Today I really try to _avoid_ ever modifying "raw" disk label slices
(partition table partitions) because it's now always determistic to
get the hardware-OS to reload the changed disk label. So by using GPT
and making lots of varying sized slices (typically 2GiB -> 4GiB ->
8GiB ... in powers of 2 until I reach the "left over" size), I can
add/remove PVs from VGs as I see fit, with_out_ having to modify any
hardware disk label. Only LVM allows such.

Just my $0.02 ...

-- bjs

P.S. Is anyone doing whole disk encryption? I've avoided it, and
only encrypt my /exports/local, /exports/server/*, etc... data
partitions, maybe swap (although I haven't tested it with hibernate).
I don't like to encrypt the boot, or anything that is not a LV, but
I'm always wary of security if I don't (hence why I also encrypt
swap).

[Kevin Korb]

I actually hope the day will come when most distributions drop support
for mounting partitions directly (except of course for other OSs and
removables). The problem I see now with most LVM supporting distros
is that they go and allocate all of the vg space at install time so
the user never gets to actually do any LVM operations. The LVM layer
just becomes some weird syntax that shows up in fstab and df.

I move the LVM2 backup configuration files from /etc to /boot because
I don't think that backup data should be dependent on the thing it is
backing up being intact. That kinda defeats the purpose. I only ever
needed the backup data once. That was back when I was first playing
with LVM2 and I backed myself into a corner where the only way I could
figure out to recover was vgcfgrestore. I only got there because I
was experimenting and there may have been a better way to recover.

The best example I can show for why LVM2 is a good thing (when you
don't actually require it for snapshots) is the migration to new
storage. With LVM2 I can migrate to new storage without a reboot.
Without LVM2 not only do I have to reboot but I have to temporarily
stop using my storage.

Here is how you would migrate a single disk system (sda1 is /boot and
sda2 is LVM2) to a new disk (sdb could be bigger, could be smaller)...

01. Insert new disk (SATA, SAS, SCSI, and USB can handle this IDE can't)
.
02. fdisk or [g]parted to make sdb1 and sdb2 (or sfdisk to copy the
partition table from sda if they happen to be the same size)
03. make a new filesystem on sdb1 with whatever options you want for
/boot.
04. mount sdb1 somewhere temporary
05. cp -a everything from /boot to wherever you mounted sdb1
06. umount /boot and sdb1 (you can mount sdb1 into /boot now if you
want but you don't have to)
07. pvcreate [--pvmetadatacopies 2] /dev/sdb2
08. vgextend <vgname> /dev/sdb2
09. pvmove /dev/sda2 /dev/sdb2
10. remove sda from the system

I have actually done that on a system with RAID before. That means I
was dealing with 4 disks instead of 2 and I had some extra mdadm steps
but it worked out the same.

Post by Bryan J Smith

Post by Shawn McMahon
You also give up all the advantages of that level of abstraction,
which makes sense only if you believe there were no problems it
was created to solve or that it's untested new technology that
hasn't had sufficient time to work out the bugs that come along
with those advantages. It's nearly as old as Linux.

And the Device Mapper generation of LVM, called version 2
(DM-LVM2), in kernel 2.6+ has *0* overhead. Whether a "block
device" is a Logical Volume (LV), partition, whole disk or other
organization -- including striping logical volumes -- it is
addressed and accessed by the kernel's Device Mapper facility the
exact _same_.
Only when LVM "features" like mirroring (which I wouldn't use --
only the newer MD-based implements), copy-on-write (including
writeable snapshots, something LVM[v1] couldn't do), etc... will
add overhead. Most of these are general Device Mapper capabilities
that LVM contains, and contains very well and ... more importantly
... _safer_ than other "containers."
And it's a virtual no-brainer when it comes to encrypted file
systems.
But, while I agree with both the Korbinator and yourself, I do
note the following cases where LVM may not be an option.
1) The sysadmin doesn't know it well, or 2) The NAND device
doesn't support discard/trim properly
I've long recognized #1 as a problem. The last thing I want is
someone with LVM who doesn't understand it. You don't have to be
a Device Mapper internals guru, and know how to recreate things
with "dmsetup," to be an LVM expert. Getting people to understand
the PV->VG-LV and, more importantly, PE~LE (Extents) aspects, plus
common operations like the [vg|lv]extend and the very pvmove
commands, are key.
I also ran into a case with #2 a long time ago. So with those
units, I will often create a root (/) on NAND with _no_ /boot or
LVM. But those days are largely long gone now.
Today I really try to _avoid_ ever modifying "raw" disk label
slices (partition table partitions) because it's now always
determistic to get the hardware-OS to reload the changed disk
label. So by using GPT and making lots of varying sized slices
(typically 2GiB -> 4GiB -> 8GiB ... in powers of 2 until I reach
the "left over" size), I can add/remove PVs from VGs as I see fit,
with_out_ having to modify any hardware disk label. Only LVM
allows such.
Just my $0.02 ...
-- bjs
P.S. Is anyone doing whole disk encryption? I've avoided it, and
only encrypt my /exports/local, /exports/server/*, etc... data
partitions, maybe swap (although I haven't tested it with
hibernate). I don't like to encrypt the boot, or anything that is
not a LV, but I'm always wary of security if I don't (hence why I
also encrypt swap).

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Bryan J Smith]

Post by Kevin Korb
I actually hope the day will come when most distributions drop support
for mounting partitions directly (except of course for other OSs and
removables).

You mean entries in /etc/fstab? Or something else?

E.g., systemd only uses /etc/fstab for "backward compatibility."
I really do like the systemd automounter myself.

Hence why I asked ... what you're looking for here.

Post by Kevin Korb
The problem I see now with most LVM supporting distros
is that they go and allocate all of the vg space at install time so
the user never gets to actually do any LVM operations. The LVM layer
just becomes some weird syntax that shows up in fstab and df.

I really _dislike_ Ubuntu's installer when it comes to this. But
that's just my view.

I've long been on the Anaconda/Kickstart list, as well as
corresponding various people internally at Red Hat over the years. I
do have to say, while the early, new Hub'n Spoke model in newer
Fedora's Anaconda was buggy at first, by RHEL7 and the recent Fedora
20+ releases, it's pretty good.

Still ... I wish it didn't do this as well. It's flexible, and
Creator knows it's better than Ubuntu's "drop to a shell and just do
it manually" (and it doesn't always read it correctly -- although the
early, new Anaconda had its troubles too), but I wish it had a few
more options.

Post by Kevin Korb
I move the LVM2 backup configuration files from /etc to /boot because
I don't think that backup data should be dependent on the thing it is
backing up being intact. That kinda defeats the purpose.

Actually, this is a really good comment. It's an outstanding comment
actually. I almost want to file a Bugzilla to have it moved
elsewhere. I mean, there's no reason why /etc/lvm can't symlink to
/boot/lvm in Fedora too.

Even for uEFI/GPT, Red Hat has already made the decision to _always_
have a separate /boot from /boot/efi, because of countless GRUB2
issues. So it doesn't need to go in /boot/efi either, which can be an
issue since it's FAT-formatted.

Post by Kevin Korb
I only ever needed the backup data once. That was back when I was
first playing with LVM2 and I backed myself into a corner where the only
way I could figure out to recover was vgcfgrestore. I only got there
because I was experimenting and there may have been a better way to
recover.

Oh man ... that's how I catch sysadmins being dishonest, especially
when they f' with the SAN or ... better yet ... to prove the SAN team
changed something.

"Oh, you didn't touch the storage provisioned to our system? Then how
come the number of blocks changed in my PV?!?!?!"

I always get that look from the SAN admins going ... "How did you know
that down to the minute?" ;)

It's kinda like why I RCS revision some files in /etc, to catch
sysadmins changing things they shouldn't. ;)

Post by Kevin Korb
The best example I can show for why LVM2 is a good thing (when you
don't actually require it for snapshots) is the migration to new
storage. With LVM2 I can migrate to new storage without a reboot.
Without LVM2 not only do I have to reboot but I have to temporarily
stop using my storage.

Yepper.

Post by Kevin Korb
Here is how you would migrate a single disk system (sda1 is /boot and
sda2 is LVM2) to a new disk (sdb could be bigger, could be smaller)...
01. Insert new disk (SATA, SAS, SCSI, and USB can handle this IDE can't)
...
10. remove sda from the system
I have actually done that on a system with RAID before. That means I
was dealing with 4 disks instead of 2 and I had some extra mdadm steps
but it worked out the same.

Once you do enough pvmoves, especially when moving around LVs before
splitting VGs (have had those cases), you don't want to go back. The
pvmove is just dang fast, because it's the kernel just doing its
thing, at raw storage-speed.

-- bjs

[Kevin Korb]

Post by Bryan J Smith

Post by Kevin Korb
I actually hope the day will come when most distributions drop
support for mounting partitions directly (except of course for
other OSs and removables).

You mean entries in /etc/fstab? Or something else?
E.g., systemd only uses /etc/fstab for "backward compatibility." I
really do like the systemd automounter myself.
Hence why I asked ... what you're looking for here.

I am not really sure what I am looking for here. Maybe just
discouragement. Maybe just a good sane initial setup. I will settle
for continuing to mock people who use "partition" when they mean "file
system".

...

Post by Bryan J Smith
Once you do enough pvmoves, especially when moving around LVs
before splitting VGs (have had those cases), you don't want to go
back. The pvmove is just dang fast, because it's the kernel just
doing its thing, at raw storage-speed.

Agreed. I am not going back to non-lvm2. Maybe I will switch from
LVM2 to BTRFS some day but it isn't there yet. It didn't even take
long to convince me once I tried it. Less than an hour of playing
with LVM2 and I was sold. Especially when it comes to running any
kind of database.

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Bryan J Smith]

Post by Kevin Korb
I am not really sure what I am looking for here. Maybe just
discouragement. Maybe just a good sane initial setup. I will settle
for continuing to mock people who use "partition" when they mean "file
system".

All my mount entries use either UUID (/boot, /boot/efi, Windows),
LABEL (if not VG-LV) or VG-LV (LVM). I always change the label when
installing too -- e.g., "(sys)[f|u](fsname)" and the like, even if the
VG-LV will be used.

Post by Kevin Korb
Agreed. I am not going back to non-lvm2. Maybe I will switch from
LVM2 to BTRFS some day but it isn't there yet.

BTRFS is basically on Red Hat's shoulders now that Oracle bought Sun
and went the ZFS route. I'm not optimistic. LVM+XFS does most
everything I need when it comes to size, even if BTFS has all that
integrated volume management.

I.e., I have been pushing Red Hat to formally adopt XFS way, way back
in 2000, well before I was even associated with them. So it's been a
long, often laughable journal (especially with Eric Sandeen, formerly
SGI, now Red Hat for over 5 years, ergo ...) Ext4 v. XFS, etc...

I was involved with the customer-ISV reasons why Red Hat _finally_
offered "Scalable File System(TM)" (XFS(R)) by 2009, and all the good
laughs Eric Sandeen (formerly SGI, now I) had over Ext4 and XFS (some
I probably cannot disclose) to the epitome of Ric Wheeler announcing
that the RHEL7 High Touch Beta would format XFS by default (sans
/boot).

Similarly happened last March-April year with Gluster v. CEPH, and
finally it became Gluster + CEPH after Red Hat bought Inktank. Again,
things I cannot talk about, but sure are funny.

So when Red Hat keeps saying it's going to try to enable BTRFS by
default, and keeps marking it "technology preview," understand there's
a good reason for that. Again, I'm not optimistic long-term. ;)

Especially when I stripe a LV across no less than eight (8) backing
devices, throw a 4TiB XFS file system on it, and destroy the
performance of most anything else in several applications. It works,
it's proven, why do I need BTRFS?

Post by Kevin Korb
It didn't even take
long to convince me once I tried it. Less than an hour of playing
with LVM2 and I was sold. Especially when it comes to running any
kind of database.

Oh man, speaking of which ... the "I gotta have the Oracle ASMlib
driver" people drive me bonkers. "No, you can skip the kernel driver"
(which is just a "root exploit" to control storage) "and use a better
solution, while still having ASMlib volumes" (just no user-level
management). Heck, even something as simple as the GPT partition
labels work extremely well for this.

I really just love having LVs in my life.

[Kevin Korb]

My big interest in BTRFS (and ZFS) is the sub-volumes. Essentially,
the ability to make snapshots on a directory level instead of a
filesystem level. This makes it very interesting for storing rsync
(instead of --link-dest) based backups. Unfortunately when I tried
using it that way it really couldn't handle it. ZFS otoh handles it
very nicely.

Post by Bryan J Smith

Post by Kevin Korb
I am not really sure what I am looking for here. Maybe just
discouragement. Maybe just a good sane initial setup. I will
settle for continuing to mock people who use "partition" when
they mean "file system".

All my mount entries use either UUID (/boot, /boot/efi, Windows),
LABEL (if not VG-LV) or VG-LV (LVM). I always change the label
when installing too -- e.g., "(sys)[f|u](fsname)" and the like,
even if the VG-LV will be used.

Post by Kevin Korb
Agreed. I am not going back to non-lvm2. Maybe I will switch
from LVM2 to BTRFS some day but it isn't there yet.

BTRFS is basically on Red Hat's shoulders now that Oracle bought
Sun and went the ZFS route. I'm not optimistic. LVM+XFS does
most everything I need when it comes to size, even if BTFS has all
that integrated volume management.
I.e., I have been pushing Red Hat to formally adopt XFS way, way
back in 2000, well before I was even associated with them. So it's
been a long, often laughable journal (especially with Eric Sandeen,
formerly SGI, now Red Hat for over 5 years, ergo ...) Ext4 v. XFS,
etc...
I was involved with the customer-ISV reasons why Red Hat _finally_
offered "Scalable File System(TM)" (XFS(R)) by 2009, and all the
good laughs Eric Sandeen (formerly SGI, now I) had over Ext4 and
XFS (some I probably cannot disclose) to the epitome of Ric Wheeler
announcing that the RHEL7 High Touch Beta would format XFS by
default (sans /boot).
Similarly happened last March-April year with Gluster v. CEPH, and
finally it became Gluster + CEPH after Red Hat bought Inktank.
Again, things I cannot talk about, but sure are funny.
So when Red Hat keeps saying it's going to try to enable BTRFS by
default, and keeps marking it "technology preview," understand
there's a good reason for that. Again, I'm not optimistic
long-term. ;)
Especially when I stripe a LV across no less than eight (8)
backing devices, throw a 4TiB XFS file system on it, and destroy
the performance of most anything else in several applications. It
works, it's proven, why do I need BTRFS?

Post by Kevin Korb
It didn't even take long to convince me once I tried it. Less
than an hour of playing with LVM2 and I was sold. Especially
when it comes to running any kind of database.

Oh man, speaking of which ... the "I gotta have the Oracle ASMlib
driver" people drive me bonkers. "No, you can skip the kernel
driver" (which is just a "root exploit" to control storage) "and
use a better solution, while still having ASMlib volumes" (just no
user-level management). Heck, even something as simple as the GPT
partition labels work extremely well for this.
I really just love having LVs in my life.

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Bryan J Smith]

Post by Kevin Korb
My big interest in BTRFS (and ZFS) is the sub-volumes. Essentially,
the ability to make snapshots on a directory level instead of a
filesystem level. This makes it very interesting for storing rsync
(instead of --link-dest) based backups. Unfortunately when I tried
using it that way it really couldn't handle it. ZFS otoh handles it
very nicely.

ZFS had a bigger team, more time and one company behind it. Early on
it had its issues, but most have been addressed.

BTRFS has had 2 primary maintainers (first Oracle, now Red Hat) and
far less time. Again, I'm not optimistic for the near-term.

Heck, I still remember when "standalone" GFS2 was the direction,
before XFS was finally adopted. Literally still cannot believe that
was ever suggested. ;)

-- bjs

[Richard F. Ostrow Jr.]

Post by Bryan J Smith
...
P.S. Is anyone doing whole disk encryption? I've avoided it, and
only encrypt my /exports/local, /exports/server/*, etc... data
partitions, maybe swap (although I haven't tested it with hibernate).
I don't like to encrypt the boot, or anything that is not a LV, but
I'm always wary of security if I don't (hence why I also encrypt
swap).

The closest I've come is an encrypted root with boot on a thumb drive
(removed after booting). I've encountered no issues related to dm-crypt
and the use of the whole disk. I'm not aware of anything that would
allow /boot to be located on an encrypted volume yet... but even if
there was, this system would not be capable of it, as my EFI firmware is
incapable of seeing my root drive device (the primary reason for the
boot from thumb drive).

I don't use LVM on that system, but I do use btrfs (most of the same
features, most of which can be done while mounted... but it's not
exactly "safe"). I've had one near-hit encounter with a filesystem
disaster, where a btrfs bug would prevent the system from mounting on
boot (space_cache issue with kernels below 3.19.5 and higher than
I-don't-remember-which). The tools needed for recovery (needed to clear
the space_cache) were luckily located in the dracut initrd (the btrfs
utility itself), but you'd need to know how to access and utilize the
recovery shell for dracut. I'd also caution against using btrfs for
large volumes... this machine has a 16 TB root (mythtv backend,
primarily), and it takes approximately 30 minutes for the mount command
to return back to the shell (much longer than systemd is willing to
wait). Every boot must be manually completed. It never complains that
the filesystem "was unmounted uncleanly" nor that there are any
filesystem errors, but it seems to take forever to mount. Once mounted,
it works fine.

I think if I were to set this system up again, I'd either try ZFS or go
back to LVM and EXT4. If I were to go back to LVM/EXT4, I'd appreciate
any reliable resources on how to utilize a systemd shutdown initrd for
the purposes of properly releasing an LVM volume on shutdown, as I've
been bitten by LVM not saving its metadata (e.g., resize operation)
changes before. It seems nobody actually uses the shutdown initrd from
systemd, as I can't find it anywhere with a google search (other than it
exists, and that it's designed to address this specific problem), and
I've been unsuccessful in attempting to set one up myself from just
reading the documentation (I just get a vague "FAILED" message on
shutdown when attempting to start the shutdown initrd service while
shutting down).

[Kevin Korb]

I do whole disk encryption on most of my personal systems. "Whole
disk" meaning that my PV's are all encrypted but /boot isn't. My dual
boot laptop is setup that way plus the Windows 7 partition is
encrypted with TrueCrypt (the version that worked).

Post by Richard F. Ostrow Jr.

... P.S. Is anyone doing whole disk encryption? I've avoided
it, and only encrypt my /exports/local, /exports/server/*, etc...
data partitions, maybe swap (although I haven't tested it with
hibernate). I don't like to encrypt the boot, or anything that is
not a LV, but I'm always wary of security if I don't (hence why I
also encrypt swap).

The closest I've come is an encrypted root with boot on a thumb
drive (removed after booting). I've encountered no issues related
to dm-crypt and the use of the whole disk. I'm not aware of
anything that would allow /boot to be located on an encrypted
volume yet... but even if there was, this system would not be
capable of it, as my EFI firmware is incapable of seeing my root
drive device (the primary reason for the boot from thumb drive).
I don't use LVM on that system, but I do use btrfs (most of the
same features, most of which can be done while mounted... but it's
not exactly "safe"). I've had one near-hit encounter with a
filesystem disaster, where a btrfs bug would prevent the system
from mounting on boot (space_cache issue with kernels below 3.19.5
and higher than I-don't-remember-which). The tools needed for
recovery (needed to clear the space_cache) were luckily located in
the dracut initrd (the btrfs utility itself), but you'd need to
know how to access and utilize the recovery shell for dracut. I'd
also caution against using btrfs for large volumes... this machine
has a 16 TB root (mythtv backend, primarily), and it takes
approximately 30 minutes for the mount command to return back to
the shell (much longer than systemd is willing to wait). Every boot
must be manually completed. It never complains that the filesystem
"was unmounted uncleanly" nor that there are any filesystem errors,
but it seems to take forever to mount. Once mounted, it works
fine.
I think if I were to set this system up again, I'd either try ZFS
or go back to LVM and EXT4. If I were to go back to LVM/EXT4, I'd
appreciate any reliable resources on how to utilize a systemd
shutdown initrd for the purposes of properly releasing an LVM
volume on shutdown, as I've been bitten by LVM not saving its
metadata (e.g., resize operation) changes before. It seems nobody
actually uses the shutdown initrd from systemd, as I can't find it
anywhere with a google search (other than it exists, and that it's
designed to address this specific problem), and I've been
unsuccessful in attempting to set one up myself from just reading
the documentation (I just get a vague "FAILED" message on shutdown
when attempting to start the shutdown initrd service while shutting
down).

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Bryan J Smith]

Post by Richard F. Ostrow Jr.
The closest I've come is an encrypted root with boot on a thumb drive
(removed after booting). I've encountered no issues related to dm-crypt and
the use of the whole disk. I'm not aware of anything that would allow /boot
to be located on an encrypted volume yet... but even if there was, this
system would not be capable of it, as my EFI firmware is incapable of seeing
my root drive device (the primary reason for the boot from thumb drive).

Executing efibootmgr with the proper information didn't add it to your
EFI firmware's bootable targets?

How about installing Rod Smith's rEFInd boot manager in the EFI System
Partition (ESP) and then having it 'find' and boot your Linux install,
irrespective of an EFI firmware entry for your Linux?

Post by Richard F. Ostrow Jr.
I don't use LVM on that system, but I do use btrfs (most of the same
features, most of which can be done while mounted... but it's not exactly
"safe") ... 16 TB root (mythtv backend, primarily) ...

To me ... the main thing that matters is that the off-line tools work,
for when something goes terribly wrong. A filesystem in flux is
always a potential gotcha for off-line tools, just like ReiserFS was
almost always.

Post by Richard F. Ostrow Jr.
I think if I were to set this system up again, I'd either try ZFS or go back
to LVM and EXT4. If I were to go back to LVM/EXT4,

Not XFS?

Since you mentioned MythTV, I'd figure that'd be a no brainer. I
mean, SGI designed it purposely in the '90s for 64-bit video servers
with tens of TBs of files. Other than the 8KiB (MIPS) v. 4KiB (x86)
page size difference that had to be addressed in 2000 for the Linux
port, XFS has been relatively unchanged -- structurally -- since the
'90s. I'm biased because I've known Eric Sandeen et al. of the
[former] SGI XFS team a long time, but he's been guru #1 on Ext4 and
XFS (ergo, hacking Ext4 with lots of features that were long inherent
to XFS).

Post by Richard F. Ostrow Jr.
I'd appreciate any reliable resources on how to utilize a systemd shutdown
initrd for the purposes of properly releasing an LVM volume on shutdown,

Er, um, what? I've never had such an issue.

What distro and what is it doing ... or not doing ... on shutdown?
Did someone forget to load a module or other support?

I mean, this is one of those areas where systemd has been outstanding,
and drastically improved over scripts. I.e., being more flexible, and
more deterministic, on calling all of the components needed to
properly shut down storage.

Especially when you have a lot of storage complexity, 20,000 paths, etc...

Post by Richard F. Ostrow Jr.
as I've been bitten by LVM not saving its metadata (e.g., resize operation)
changes before.

Whoa, whoa, whoa! I'm not following you here at all.

LVM metadata is change at time of change -- such as a resize -- and
that's that. I mean, a LVM resize is virtually instantaneous! It's
just allocating more PEs from PVs assigned in the VG to the LEs of the
LV. Either you have the PEs, or you don't, and it's an extremely fast
Device Mapper operation that just updates the LVM meta-data when done.

Are you using "-r" with lvresize or something? I don't recommend it.
I would do a discrete "lvresize" and then a discrete "resize2fs." The
former is virtually instantaneous. The latter takes awhile, hence why
I never use "-r" with lvresize. But even then I don't see how "-r"
would cause issues, the LVM change "just happens" and it _should_
always be an O_DIRECT operation.

Was this on a NAND device with discard enabled, but the device didn't
support it proper? That's the only time I think something like this
could ever occur.

The only other time LVM writes to its meta is when it goes from active
to inactive, from use to clean. But even if you don't properly shut
down, then it shouldn't have any issue. But as Korbinator says,
that's what the backups are for, although they probably should be in
/boot instead of /etc.

Post by Richard F. Ostrow Jr.
It seems nobody actually uses the shutdown initrd from systemd, as I
can't find it anywhere with a google search (other than it exists, and that
it's designed to address this specific problem), and I've been unsuccessful
in attempting to set one up myself from just reading the documentation (I
just get a vague "FAILED" message on shutdown when attempting to start the
shutdown initrd service while shutting down).

Again, what distro is this?
And what kind of storage and/or other organization are you using?

The only thing I can think of is that you are using something that
doesn't have an entry/support in the shutdown, and prevents your VGs
from going inactive, because you don't have the support to unmount
file systems and do other things.

I.e., something gets "left open."

But that still would _not_ explain why your LVM meta-data gets
corrupted. LVM meta-data operations -- which go to the reservation in
the PV itself -- are O_DIRECT, first journaled (LVM has its own), then
applied (to the official meta-data block). Other than the use/clean
for inactive/active, it's not going to be written to, and even that is
separate.

I've never seen this. An improper shutdown should _never_ affect LVM
meta-data. It's written explicitly _not_ to do such, via its journal
and the PV design.

There must be something else involved that's causing issues, and not
actually respecting O_DIRECT to the LVM meta-data in the PVs. That's
the only thing I could think of.

-- bjs

[Richard F. Ostrow Jr.]

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
The closest I've come is an encrypted root with boot on a thumb drive
(removed after booting). I've encountered no issues related to dm-crypt and
the use of the whole disk. I'm not aware of anything that would allow /boot
to be located on an encrypted volume yet... but even if there was, this
system would not be capable of it, as my EFI firmware is incapable of seeing
my root drive device (the primary reason for the boot from thumb drive).

Executing efibootmgr with the proper information didn't add it to your
EFI firmware's bootable targets?
How about installing Rod Smith's rEFInd boot manager in the EFI System
Partition (ESP) and then having it 'find' and boot your Linux install,
irrespective of an EFI firmware entry for your Linux?

I haven't tried using efibootmgr directly, just grub2-install. I'm
installing onto a hardware RAID card that pre-dates EFI capabilities
(Areca ARC-1231), and when I was looking up the symptoms, it seemed that
the consensus was that EFI and older MS-DOS style RAID cards don't play
well together. The easy solution was to boot via EFI to a thumb drive
and by the time the kernel loads, the RAID card is initialized and ready
to go.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
I think if I were to set this system up again, I'd either try ZFS or go back
to LVM and EXT4. If I were to go back to LVM/EXT4,

Not XFS?
Since you mentioned MythTV, I'd figure that'd be a no brainer. I
mean, SGI designed it purposely in the '90s for 64-bit video servers
with tens of TBs of files. Other than the 8KiB (MIPS) v. 4KiB (x86)
page size difference that had to be addressed in 2000 for the Linux
port, XFS has been relatively unchanged -- structurally -- since the
'90s. I'm biased because I've known Eric Sandeen et al. of the
[former] SGI XFS team a long time, but he's been guru #1 on Ext4 and
XFS (ergo, hacking Ext4 with lots of features that were long inherent
to XFS).

Yeah, I'm considering XFS as well, though I'm still leaning toward ZFS
of the three (more research may well change that - I'm not ready to
convert yet).

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
I'd appreciate any reliable resources on how to utilize a systemd shutdown
initrd for the purposes of properly releasing an LVM volume on shutdown,

Er, um, what? I've never had such an issue.
What distro and what is it doing ... or not doing ... on shutdown?
Did someone forget to load a module or other support?

This is a gentoo box. At the time I was running LVM, it was never able
to shutdown properly. I've seen some grumbling (let's call them rumors,
since it's been so long) that it may be because I was using LUKS on the
bottom layer, with LVM on top of it, and early systemd may have had
issues with that. I'm considering LVM and ext4 again because I hope it's
been long enough that such issues have been worked out by now.

Post by Bryan J Smith
I mean, this is one of those areas where systemd has been outstanding,
and drastically improved over scripts. I.e., being more flexible, and
more deterministic, on calling all of the components needed to
properly shut down storage.
Especially when you have a lot of storage complexity, 20,000 paths, etc...

Post by Richard F. Ostrow Jr.
as I've been bitten by LVM not saving its metadata (e.g., resize operation)
changes before.

Whoa, whoa, whoa! I'm not following you here at all.
LVM metadata is change at time of change -- such as a resize -- and
that's that. I mean, a LVM resize is virtually instantaneous! It's
just allocating more PEs from PVs assigned in the VG to the LEs of the
LV. Either you have the PEs, or you don't, and it's an extremely fast
Device Mapper operation that just updates the LVM meta-data when done.
Are you using "-r" with lvresize or something? I don't recommend it.
I would do a discrete "lvresize" and then a discrete "resize2fs." The
former is virtually instantaneous. The latter takes awhile, hence why
I never use "-r" with lvresize. But even then I don't see how "-r"
would cause issues, the LVM change "just happens" and it _should_
always be an O_DIRECT operation.

Wasn't using "-r", it was two discrete commands. It ran great until I
shutdown, at which point it lost its mind on startup. I got my "LVM
failed to stop" message from systemd while shutting down (which was
normally harmless on boots where I did _not_ change the metadata), but
this time it lost it. I lost a few months of TV recordings (I was
expanding my RAID array to accommodate new hard drives), which was
inconvenient but not fatal.

Post by Bryan J Smith
Was this on a NAND device with discard enabled, but the device didn't
support it proper? That's the only time I think something like this
could ever occur.

Just a RAID-6 device with write-back enabled and barriers turned off
(battery backup on the card).

Post by Bryan J Smith
The only other time LVM writes to its meta is when it goes from active
to inactive, from use to clean. But even if you don't properly shut
down, then it shouldn't have any issue. But as Korbinator says,
that's what the backups are for, although they probably should be in
/boot instead of /etc.

If I go with LVM again, I'll definately make backups in /boot

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
It seems nobody actually uses the shutdown initrd from systemd, as I
can't find it anywhere with a google search (other than it exists, and that
it's designed to address this specific problem), and I've been unsuccessful
in attempting to set one up myself from just reading the documentation (I
just get a vague "FAILED" message on shutdown when attempting to start the
shutdown initrd service while shutting down).

Again, what distro is this?
And what kind of storage and/or other organization are you using?

Gentoo. At the time, I was using 12 1TB HDDs on an ARC-1231 RAID card in
a RAID-6 configuration (10 TB total) with GPT and no EFI. I am now using
the same card on 6 4 TB drives, still on a RAID-6 (16 TB total), running
EFI and GPT. I figure one day, 2.5" 4 TB HDDs may become affordable and
I can consider expanding this array, as I only have 2.5" slots left on
the server.

Post by Bryan J Smith
The only thing I can think of is that you are using something that
doesn't have an entry/support in the shutdown, and prevents your VGs
from going inactive, because you don't have the support to unmount
file systems and do other things.
I.e., something gets "left open."

Not even sure where to look for something like that :(

Post by Bryan J Smith
But that still would _not_ explain why your LVM meta-data gets
corrupted. LVM meta-data operations -- which go to the reservation in
the PV itself -- are O_DIRECT, first journaled (LVM has its own), then
applied (to the official meta-data block). Other than the use/clean
for inactive/active, it's not going to be written to, and even that is
separate.
I've never seen this. An improper shutdown should _never_ affect LVM
meta-data. It's written explicitly _not_ to do such, via its journal
and the PV design.
There must be something else involved that's causing issues, and not
actually respecting O_DIRECT to the LVM meta-data in the PVs. That's
the only thing I could think of.

That's possible. The only thing I can point to LVM about on this is that
LVM was complaining on not being shutdown properly the last time it was
shut down after the metadata was changed, and on the next startup it was
unusable. It's possible that LUKS failed to update its metadata as it
was resized, or ext4 failed to update its metadata as it was resized...
but I only got the failure message for LVM.

Post by Bryan J Smith
-- bjs
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Kevin Korb]

I run Gentoo and I have ext4 on top of lvm on top of luks on top of
both mdraid and an Areca controller (ARC-1120). The only issue I have
had is that the Areca controller doesn't work properly if the driver
is built into the kernel so I have to make an initrd to load the
module before my lvm vg is complete. I use a customized
better-initramfs for that (I just added my modules directory and a
modprobe line in their script).

Post by Richard F. Ostrow Jr.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
The closest I've come is an encrypted root with boot on a thumb
drive (removed after booting). I've encountered no issues
related to dm-crypt and the use of the whole disk. I'm not
aware of anything that would allow /boot to be located on an
encrypted volume yet... but even if there was, this system
would not be capable of it, as my EFI firmware is incapable of
seeing my root drive device (the primary reason for the boot
from thumb drive).

Executing efibootmgr with the proper information didn't add it to
your EFI firmware's bootable targets?
How about installing Rod Smith's rEFInd boot manager in the EFI
System Partition (ESP) and then having it 'find' and boot your
Linux install, irrespective of an EFI firmware entry for your
Linux?

I haven't tried using efibootmgr directly, just grub2-install. I'm
installing onto a hardware RAID card that pre-dates EFI
capabilities (Areca ARC-1231), and when I was looking up the
symptoms, it seemed that the consensus was that EFI and older
MS-DOS style RAID cards don't play well together. The easy solution
was to boot via EFI to a thumb drive and by the time the kernel
loads, the RAID card is initialized and ready to go.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
I think if I were to set this system up again, I'd either try
ZFS or go back to LVM and EXT4. If I were to go back to
LVM/EXT4,

Not XFS?
Since you mentioned MythTV, I'd figure that'd be a no brainer.
I mean, SGI designed it purposely in the '90s for 64-bit video
servers with tens of TBs of files. Other than the 8KiB (MIPS) v.
4KiB (x86) page size difference that had to be addressed in 2000
for the Linux port, XFS has been relatively unchanged --
structurally -- since the '90s. I'm biased because I've known
Eric Sandeen et al. of the [former] SGI XFS team a long time, but
he's been guru #1 on Ext4 and XFS (ergo, hacking Ext4 with lots
of features that were long inherent to XFS).

Yeah, I'm considering XFS as well, though I'm still leaning toward
ZFS of the three (more research may well change that - I'm not
ready to convert yet).

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
I'd appreciate any reliable resources on how to utilize a
systemd shutdown initrd for the purposes of properly releasing
an LVM volume on shutdown,

Er, um, what? I've never had such an issue.
What distro and what is it doing ... or not doing ... on
shutdown? Did someone forget to load a module or other support?

This is a gentoo box. At the time I was running LVM, it was never
able to shutdown properly. I've seen some grumbling (let's call
them rumors, since it's been so long) that it may be because I was
using LUKS on the bottom layer, with LVM on top of it, and early
systemd may have had issues with that. I'm considering LVM and ext4
again because I hope it's been long enough that such issues have
been worked out by now.

Post by Bryan J Smith
I mean, this is one of those areas where systemd has been
outstanding, and drastically improved over scripts. I.e., being
more flexible, and more deterministic, on calling all of the
components needed to properly shut down storage.
Especially when you have a lot of storage complexity, 20,000
paths, etc...

Post by Richard F. Ostrow Jr.
as I've been bitten by LVM not saving its metadata (e.g.,
resize operation) changes before.

Whoa, whoa, whoa! I'm not following you here at all.
LVM metadata is change at time of change -- such as a resize --
and that's that. I mean, a LVM resize is virtually
instantaneous! It's just allocating more PEs from PVs assigned
in the VG to the LEs of the LV. Either you have the PEs, or you
don't, and it's an extremely fast Device Mapper operation that
just updates the LVM meta-data when done.
Are you using "-r" with lvresize or something? I don't recommend
it. I would do a discrete "lvresize" and then a discrete
"resize2fs." The former is virtually instantaneous. The latter
takes awhile, hence why I never use "-r" with lvresize. But even
then I don't see how "-r" would cause issues, the LVM change
"just happens" and it _should_ always be an O_DIRECT operation.

Wasn't using "-r", it was two discrete commands. It ran great until
I shutdown, at which point it lost its mind on startup. I got my
"LVM failed to stop" message from systemd while shutting down
(which was normally harmless on boots where I did _not_ change the
metadata), but this time it lost it. I lost a few months of TV
recordings (I was expanding my RAID array to accommodate new hard
drives), which was inconvenient but not fatal.

Post by Bryan J Smith
Was this on a NAND device with discard enabled, but the device
didn't support it proper? That's the only time I think something
like this could ever occur.

Just a RAID-6 device with write-back enabled and barriers turned
off (battery backup on the card).

Post by Bryan J Smith
The only other time LVM writes to its meta is when it goes from
active to inactive, from use to clean. But even if you don't
properly shut down, then it shouldn't have any issue. But as
Korbinator says, that's what the backups are for, although they
probably should be in /boot instead of /etc.

If I go with LVM again, I'll definately make backups in /boot

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
It seems nobody actually uses the shutdown initrd from systemd,
as I can't find it anywhere with a google search (other than it
exists, and that it's designed to address this specific
problem), and I've been unsuccessful in attempting to set one
up myself from just reading the documentation (I just get a
vague "FAILED" message on shutdown when attempting to start
the shutdown initrd service while shutting down).

Again, what distro is this? And what kind of storage and/or other
organization are you using?

Gentoo. At the time, I was using 12 1TB HDDs on an ARC-1231 RAID
card in a RAID-6 configuration (10 TB total) with GPT and no EFI. I
am now using the same card on 6 4 TB drives, still on a RAID-6 (16
TB total), running EFI and GPT. I figure one day, 2.5" 4 TB HDDs
may become affordable and I can consider expanding this array, as I
only have 2.5" slots left on the server.

Post by Bryan J Smith
The only thing I can think of is that you are using something
that doesn't have an entry/support in the shutdown, and prevents
your VGs from going inactive, because you don't have the support
to unmount file systems and do other things.
I.e., something gets "left open."

Not even sure where to look for something like that :(

Post by Bryan J Smith
But that still would _not_ explain why your LVM meta-data gets
corrupted. LVM meta-data operations -- which go to the
reservation in the PV itself -- are O_DIRECT, first journaled
(LVM has its own), then applied (to the official meta-data
block). Other than the use/clean for inactive/active, it's not
going to be written to, and even that is separate.
I've never seen this. An improper shutdown should _never_ affect
LVM meta-data. It's written explicitly _not_ to do such, via its
journal and the PV design.
There must be something else involved that's causing issues, and
not actually respecting O_DIRECT to the LVM meta-data in the PVs.
That's the only thing I could think of.

That's possible. The only thing I can point to LVM about on this is
that LVM was complaining on not being shutdown properly the last
time it was shut down after the metadata was changed, and on the
next startup it was unusable. It's possible that LUKS failed to
update its metadata as it was resized, or ext4 failed to update its
metadata as it was resized... but I only got the failure message
for LVM.

Post by Bryan J Smith
-- bjs
_______________________________________________ Tech mailing

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Steve Litt]

On Fri, 7 Aug 2015 18:30:59 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
so I have to make an initrd to load the
module before my lvm vg is complete. I use a customized
better-initramfs for that (I just added my modules directory and a
modprobe line in their script).

Kevin,

It would be very cool if you gave a GoLUG presentation where you show
exactly how you make these initramfs'. The days of these things being
optional are long gone.

Thanks,

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Kevin Korb]

Normally, you just unpack it and run make. But since you seem to want
something fancy...

#!/bin/csh -f

# determine kernel version...
set Kernel=`readlink /usr/src/linux | sed -e 's/^linux-//' -e 's/\///'`

# Determine how many CPUs the system has...
set ProcNum=`grep ^processor /proc/cpuinfo | tail -n1 | awk '{print $NF}
'`
# use numcpus+1 threads while compiling the kernel...
set NumProc=`echo ${ProcNum}+1 | bc`
set Jobs="-j${NumProc}"

rsync -vai --delete --delete-excluded --include="/${Kernel}/***"
- --exclude='*' /lib/modules/ sourceroot/lib/modules/
bootstrap/bootstrap-all || exec echo "bootstrap failed"
make $Jobs prepare || exec echo "prepare failed"
make $Jobs image || exec echo "image failed"
mv -fv output/initramfs.cpio.gz output/initramfs-${Kernel}.cpio.gz
cp -iav output/initramfs-${Kernel}.cpio.gz /boot/

Post by Steve Litt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
so I have to make an initrd to load the module before my lvm vg
is complete. I use a customized better-initramfs for that (I
just added my modules directory and a modprobe line in their
script).

Kevin,
It would be very cool if you gave a GoLUG presentation where you
show exactly how you make these initramfs'. The days of these
things being optional are long gone.
Thanks,
SteveT
Steve Litt July 2015 featured book: Rapid Learning for the 21st
Century http://www.troubleshooters.com/rl21
_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Bryan J Smith]

Post by Kevin Korb
I run Gentoo and I have ext4 on top of lvm on top of luks on top of
both mdraid and an Areca controller (ARC-1120). The only issue I have
had is that the Areca controller doesn't work properly if the driver
is built into the kernel so I have to make an initrd to load the
module before my lvm vg is complete. I use a customized
better-initramfs for that (I just added my modules directory and a
modprobe line in their script).

Most distro initrd creation scripts are either good at ...
A) Automatically ordering HBA, storage, etc... before MD, LVM, etc.., or
B) Giving the sysadmin the option to preload in correct order

Although I do have to admit, Gentoo has been a complete non-starter
for Boot-from-SAN, among other, advanced storage environments, so I
gave up on it for anything but basic storage long ago.

That all said ...

I thought Gentoo was adopting Dracut like most other distros? I
haven't had a _single_ issue with any Dracut-based distro, at least
not after early "teething" issues when distros first adopt it.

The "rdshell" is also sweet, plus there is the "rd.break" to exit at
various breakpoints, or just at the end. Most people think this is a
systemd-thing, when it's _not_. The "rd.break" in Dracut has always
been much, much _safer_ way to "break out" of boot pre (or just after
post) pivot, than "you're on your own" solutions like
"init=/bin/bash".

Especially when one is using MD, DM-MPIO or other, advanced storage
organization where you want to make sure the "meta" device is used ...
and not the "raw" where you could screw up things. I wouldn't mention
this except from experience ... where a sysadmin royally _destroys_ --
at best -- a partition table (I then have to recover) or -- more often
-- instigates actual data loss.

-- bjs

[Richard F. Ostrow Jr.]

Post by Bryan J Smith

Post by Kevin Korb
I run Gentoo and I have ext4 on top of lvm on top of luks on top of
both mdraid and an Areca controller (ARC-1120). The only issue I have
had is that the Areca controller doesn't work properly if the driver
is built into the kernel so I have to make an initrd to load the
module before my lvm vg is complete. I use a customized
better-initramfs for that (I just added my modules directory and a
modprobe line in their script).

Most distro initrd creation scripts are either good at ...
A) Automatically ordering HBA, storage, etc... before MD, LVM, etc.., or
B) Giving the sysadmin the option to preload in correct order
Although I do have to admit, Gentoo has been a complete non-starter
for Boot-from-SAN, among other, advanced storage environments, so I
gave up on it for anything but basic storage long ago.
That all said ...
I thought Gentoo was adopting Dracut like most other distros? I
haven't had a _single_ issue with any Dracut-based distro, at least
not after early "teething" issues when distros first adopt it.

I've been using dracut for quite a while now under gentoo, and I was
using it back then when I had these issues as well. It did everything my
manual scripts did, and it did it while following the appropriate
standards. It also was a whole lot easier to maintain, and worked when
my scripts started failing when LVM changed its initrd requirements.
Sounded like a win-win to me. The only downside is it wasn't quite as
"minimal" as my scripts were... but it worked after every
kernel/LVM/{other initrd-necessary binary} update, so it was worth it as
far as I was concerned.

Post by Bryan J Smith
The "rdshell" is also sweet, plus there is the "rd.break" to exit at
various breakpoints, or just at the end. Most people think this is a
systemd-thing, when it's _not_. The "rd.break" in Dracut has always
been much, much _safer_ way to "break out" of boot pre (or just after
post) pivot, than "you're on your own" solutions like
"init=/bin/bash".

Absolutely agree, although I'll admit I can never remember that
parameter without looking it up. It's really something worth memorizing.

[Steve Litt]

On Sun, 9 Aug 2015 01:08:25 -0400

Post by Bryan J Smith
The "rdshell" is also sweet, plus there is the "rd.break" to exit at
various breakpoints, or just at the end. Most people think this is a
systemd-thing, when it's _not_. The "rd.break" in Dracut has always
been much, much _safer_ way to "break out" of boot pre (or just after
post) pivot, than "you're on your own" solutions like
"init=/bin/bash".

If rdshell is that busybox-like interface that emerges on Ubuntu 15.04
when you specify "init=/bin/bash", I'm having trouble with it. To me,
"init=/bin/bash" is a periscope with which you pop up, look around
*with bash*, see what's going on, run the proper software manually, load
the proper drivers, mount the proper devices on the proper mountpoints.
You slowly bring the system up one step at a time so as to figure out
either what went wrong, or to figure out how you're going to do it your
own way.

I was unable to do any of this with "init=/bin/bash" on Ubuntu 15.04.
It was as if I popped up in the middle of the initramfs run script
itself, before the root partition was mounted, and no switch-root (I
think my switch-root is what you call it pivot) had been done. There
was no switch-root executable available. This was on a plain vanilla no
partitions but root ext4.

Is there a different name for switch-root within rdshell?

Post by Bryan J Smith
Especially when one is using MD, DM-MPIO or other, advanced storage
organization where you want to make sure the "meta" device is used ...
and not the "raw" where you could screw up things. I wouldn't mention
this except from experience ... where a sysadmin royally _destroys_ --
at best -- a partition table (I then have to recover) or -- more often
-- instigates actual data loss.
-- bjs

I see the value in safety, and on my daily driver I might do exactly
what you recommend. In the use case of DIY experimentation, however,
I need to go in with "init=/bin/bash", look around, figure out what's
necessary, and if I break something, just go back to a VM snapshot.


SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Shawn McMahon]

No, rdshell is what pops up when you add rdshell to your kernel command
line. The busybox-like interface that emerges when you add "init=/bin/bash"
is called "bash".

Post by Steve Litt
On Sun, 9 Aug 2015 01:08:25 -0400

Post by Bryan J Smith
The "rdshell" is also sweet, plus there is the "rd.break" to exit at
various breakpoints, or just at the end. Most people think this is a
systemd-thing, when it's _not_. The "rd.break" in Dracut has always
been much, much _safer_ way to "break out" of boot pre (or just after
post) pivot, than "you're on your own" solutions like
"init=/bin/bash".

If rdshell is that busybox-like interface that emerges on Ubuntu 15.04
when you specify "init=/bin/bash", I'm having trouble with it. To me,
"init=/bin/bash" is a periscope with which you pop up, look around
*with bash*, see what's going on, run the proper software manually, load
the proper drivers, mount the proper devices on the proper mountpoints.
You slowly bring the system up one step at a time so as to figure out
either what went wrong, or to figure out how you're going to do it your
own way.
I was unable to do any of this with "init=/bin/bash" on Ubuntu 15.04.
It was as if I popped up in the middle of the initramfs run script
itself, before the root partition was mounted, and no switch-root (I
think my switch-root is what you call it pivot) had been done. There
was no switch-root executable available. This was on a plain vanilla no
partitions but root ext4.
Is there a different name for switch-root within rdshell?

Post by Bryan J Smith
Especially when one is using MD, DM-MPIO or other, advanced storage
organization where you want to make sure the "meta" device is used ...
and not the "raw" where you could screw up things. I wouldn't mention
this except from experience ... where a sysadmin royally _destroys_ --
at best -- a partition table (I then have to recover) or -- more often
-- instigates actual data loss.
-- bjs

I see the value in safety, and on my daily driver I might do exactly
what you recommend. In the use case of DIY experimentation, however,
I need to go in with "init=/bin/bash", look around, figure out what's
necessary, and if I break something, just go back to a VM snapshot.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Steve Litt]

Thanks Shawn,

Thinking about it, it *could* be bash, given that the hard
disk's /bin, /usr/bin, /usr/sbin and /bin aren't accessible. I was just
assuming that an environment with almost none of the ordinary commands
you use every day is busybox or something like it.

On Sun, 9 Aug 2015 12:27:19 -0400

Post by Shawn McMahon
No, rdshell is what pops up when you add rdshell to your kernel
command line. The busybox-like interface that emerges when you add
"init=/bin/bash" is called "bash".
On Sun, Aug 9, 2015 at 12:02 PM, Steve Litt

Post by Steve Litt
On Sun, 9 Aug 2015 01:08:25 -0400

Post by Bryan J Smith
The "rdshell" is also sweet, plus there is the "rd.break" to exit
at various breakpoints, or just at the end. Most people think
this is a systemd-thing, when it's _not_. The "rd.break" in
Dracut has always been much, much _safer_ way to "break out" of
boot pre (or just after post) pivot, than "you're on your own"
solutions like "init=/bin/bash".

If rdshell is that busybox-like interface that emerges on Ubuntu
15.04 when you specify "init=/bin/bash", I'm having trouble with
it. To me, "init=/bin/bash" is a periscope with which you pop up,
look around *with bash*, see what's going on, run the proper
software manually, load the proper drivers, mount the proper
devices on the proper mountpoints. You slowly bring the system up
one step at a time so as to figure out either what went wrong, or
to figure out how you're going to do it your own way.
I was unable to do any of this with "init=/bin/bash" on Ubuntu
15.04. It was as if I popped up in the middle of the initramfs run
script itself, before the root partition was mounted, and no
switch-root (I think my switch-root is what you call it pivot) had
been done. There was no switch-root executable available. This was
on a plain vanilla no partitions but root ext4.
Is there a different name for switch-root within rdshell?

Post by Bryan J Smith
Especially when one is using MD, DM-MPIO or other, advanced
storage organization where you want to make sure the "meta"
device is used ... and not the "raw" where you could screw up
things. I wouldn't mention this except from experience ... where
a sysadmin royally _destroys_ -- at best -- a partition table (I
then have to recover) or -- more often -- instigates actual data
loss.
-- bjs

I see the value in safety, and on my daily driver I might do exactly
what you recommend. In the use case of DIY experimentation, however,
I need to go in with "init=/bin/bash", look around, figure out
what's necessary, and if I break something, just go back to a VM
snapshot.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

Post by Steve Litt
If rdshell is that busybox-like interface that emerges on
Ubuntu 15.04 when you specify "init=/bin/bash", I'm having
trouble with it.
No, rdshell is what pops up when you add rdshell to your
kernel command line. The busybox-like interface that emerges
when you add "init=/bin/bash" is called "bash".

Why do I suddenly feel like Eddie Murphy ... yet again? [1]

Post by Steve Litt
To me, "init=/bin/bash" is a periscope with which you pop up,
look around *with bash*, see what's going on, run the proper
software manually, load the proper drivers, mount the proper
devices on the proper mountpoints.

To me ...

"rd.break" lets me see _exactly_ what the system will load, so I can
see _exactly_ what it's doing right ... or wrong.

To do it manually is to instigate manual errors, miss steps, make
(often wrong) assumptions, etc...

Post by Steve Litt
You slowly bring the system up one step at a time so as to figure out
either what went wrong, or to figure out how you're going to do it your
own way.

Actually, that's "rd.break" to me.

With "init=/bin/bash" I have _no_ rd, no sequence, _nothing_.

Post by Steve Litt
I was unable to do any of this with "init=/bin/bash" on Ubuntu 15.04.

Obviously.

Because systems have reached the point of complexity that asking a
sysadmin to run "init=/bin/bash" and "debug" the system is kinda like
asking an arts major who barely made it through algebra to figure out
how they will pay for their college loans (much less understand
something like "future value").

I.e., it's easier to show the arts major (and even many business
majors these days) the basics in how to use a financial calculator,
than go through the "proof" of something like "future value."

In the same regard ... sysadmins should be using "rd.break" these days.

Post by Steve Litt
It was as if I popped up in the middle of the initramfs run script
itself, before the root partition was mounted, and no switch-root (I
think my switch-root is what you call it pivot) had been done. There
was no switch-root executable available. This was on a plain vanilla no
partitions but root ext4.
Is there a different name for switch-root within rdshell?

Can you break open a dracut-created initrd? If so ... you can figure
out how rd "breakpoints" work, and what they give you. ;)

That's not an insult. It's actually a question that will hopefully
drive you to learn why they are very powerful, and why sysadmins
should use them today. Because I know once you do, we'll learn
everything about them in a most excellent, future Troubleshooters.COM
article. ;)

Post by Steve Litt
I see the value in safety, and on my daily driver I might do exactly
what you recommend. In the use case of DIY experimentation, however,
I need to go in with "init=/bin/bash", look around, figure out what's
necessary, and if I break something, just go back to a VM snapshot.

And I see value in avoiding NIH.

I used to be a NIH guy back in my teenage and even early 20s. Then I
realized I'd rather be spending time with my wife ... or should I say
more empirically ...

It's "future value." ;)

-- bjs

[1] Looking directly into the camera at the end of these final, 7 seconds ...
-

[Steve Litt]

On Sun, 9 Aug 2015 13:11:01 -0400

Post by Bryan J Smith
To me ...
"rd.break" lets me see _exactly_ what the system will load, so I can
see _exactly_ what it's doing right ... or wrong.

Is rd.break available and useable on systems with no systemd, including
vdev or eudev instead of systemd's udev? If so, I can use it on my
upcoming daily driver desktop (I obviously can use it on Ubuntu 15.04)

[snip]

Post by Bryan J Smith

Post by Steve Litt
I was unable to do any of this with "init=/bin/bash" on Ubuntu 15.04.

Obviously.
Because systems have reached the point of complexity that asking a
sysadmin to run "init=/bin/bash" and "debug" the system is kinda like
asking an arts major who barely made it through algebra to figure out
how they will pay for their college loans (much less understand
something like "future value").

Yeah, but I'm not an arts major.

When you run with init=/bin/bash, you're supposed to pop up in bash
after the initramfs finishes. I'm not quite sure what the purpose of
finishing initramfs with the root partition still not mounted is. After
all, what people are telling me is the whole purpose of initramfs is to
load enough drivers and do enough other stuff that you can get your
root partition mounted, regardless of ext4 or zfs or lvm or luks. If
initramfs finishes, leaving the root partition unmounted and the
ramdisk's content uncopied to the root partition, I'm wondering if
initramfs did its whole job. I mean, really, how hard is it to put a
switch-root command at the end of initramfs, and what would be the
motivation for *not* doing so, given that if you did so, even art
majors would be able to trace the post initramfs boot.

[snip]

Post by Bryan J Smith
And I see value in avoiding NIH.
I used to be a NIH guy back in my teenage and even early 20s. Then I
realized I'd rather be spending time with my wife ... or should I say
more empirically ...

I see a lot of the replacement of tools Unix gave us with complex
networks of functionalities, connected with thick interfaces, as NIH. I
see the current trend toward minimalism as *avoiding* NIH.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

Post by Steve Litt
Is rd.break available and useable on systems with no systemd, including
vdev or eudev instead of systemd's udev? If so, I can use it on my
upcoming daily driver desktop (I obviously can use it on Ubuntu 15.04)

You not only know the answer to this question ...

*BUT* you even _quoted_ the answer earlier ... ;)
(CAPS ... so you dont' miss it ...)

On Sun, Aug 9, 2015 at 12:02 PM,

Post by Steve Litt
On Sun, 9 Aug 2015 01:08:25 -0400,

Post by Bryan J Smith
The "rdshell" is also sweet, plus there is the "rd.break"
to exit at various breakpoints, or just at the end.
MOST PEOPLE THINK THIS IS A SYSTEMD-THING,
WHEN IT'S _NOT_. THE "rd.break" IN DRACUT HAS
ALWAYS BEEN A MUCH, MUCH _SAFER_ WAY to
"break out" of boot pre (or just after post) pivot
than "you're on your own" solutions like
"init=/bin/bash".

Yeah, but I'm not an arts major.

Exactly! If I'm going to mention something and useful, and re-mention
you should look at it ... I _know_ you will. ;)

Post by Steve Litt
When you run with init=/bin/bash, you're supposed to pop up in bash
after the initramfs finishes. I'm not quite sure what the purpose of
finishing initramfs with the root partition still not mounted is.

It all depends. ;)

Post by Steve Litt
I see a lot of the replacement of tools Unix gave us with complex
networks of functionalities, connected with thick interfaces, as NIH. I
see the current trend toward minimalism as *avoiding* NIH.

And yet ...

A lot of things Dracut, systemd, etc... do, systematically,
deterministically, etc... seem to be ignored by people who push a lot
of custom, spaghetti code that is 10x more complex, and 1/10th as
useful.

It's one thing to want to do something manually to understand
something deeper. But when you're _ignoring_ all of the capabilities
that have been introduced to make your life not only easier, but
troubleshooting 100x more useful, it's kinda hard to understand the
argument.

In many cases, it's "Not Invented Here" (NIH), because it very much is
a "my way is better" attitude.

Which is, sadly, where a lot of Gentoo users shoot themselves in the foot.

-- bjs

[Bryan J Smith]

Dude thats your problem right there the card must support you feed the you
feat post must be able to load the storage support not interrupt 13 by the
services if you have an older card it only has interrupt 13 de services
from the old 16 bit biased with out you please support with out a USB
storage target the compatibility support module CSM is going to load and be
in the legacy BIOS mode hence why you feed doesn't work you're not booting
into you feat and if you use GPT you'll have to use a BIOS boot partition
it won't be native

DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith - Technology Mercenary

Post by Richard F. Ostrow Jr.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
The closest I've come is an encrypted root with boot on a thumb drive
(removed after booting). I've encountered no issues related to dm-crypt and
the use of the whole disk. I'm not aware of anything that would allow /boot
to be located on an encrypted volume yet... but even if there was, this
system would not be capable of it, as my EFI firmware is incapable of seeing
my root drive device (the primary reason for the boot from thumb drive).

Executing efibootmgr with the proper information didn't add it to your
EFI firmware's bootable targets?
How about installing Rod Smith's rEFInd boot manager in the EFI System
Partition (ESP) and then having it 'find' and boot your Linux install,
irrespective of an EFI firmware entry for your Linux?

I haven't tried using efibootmgr directly, just grub2-install. I'm
installing onto a hardware RAID card that pre-dates EFI capabilities (Areca
ARC-1231), and when I was looking up the symptoms, it seemed that the
consensus was that EFI and older MS-DOS style RAID cards don't play well
together. The easy solution was to boot via EFI to a thumb drive and by the
time the kernel loads, the RAID card is initialized and ready to go.
I think if I were to set this system up again, I'd either try ZFS or go

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
back
to LVM and EXT4. If I were to go back to LVM/EXT4,

Not XFS?
Since you mentioned MythTV, I'd figure that'd be a no brainer. I
mean, SGI designed it purposely in the '90s for 64-bit video servers
with tens of TBs of files. Other than the 8KiB (MIPS) v. 4KiB (x86)
page size difference that had to be addressed in 2000 for the Linux
port, XFS has been relatively unchanged -- structurally -- since the
'90s. I'm biased because I've known Eric Sandeen et al. of the
[former] SGI XFS team a long time, but he's been guru #1 on Ext4 and
XFS (ergo, hacking Ext4 with lots of features that were long inherent
to XFS).

Yeah, I'm considering XFS as well, though I'm still leaning toward ZFS of
the three (more research may well change that - I'm not ready to convert
yet).
I'd appreciate any reliable resources on how to utilize a systemd shutdown

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
initrd for the purposes of properly releasing an LVM volume on shutdown,

Er, um, what? I've never had such an issue.
What distro and what is it doing ... or not doing ... on shutdown?
Did someone forget to load a module or other support?

This is a gentoo box. At the time I was running LVM, it was never able to
shutdown properly. I've seen some grumbling (let's call them rumors, since
it's been so long) that it may be because I was using LUKS on the bottom
layer, with LVM on top of it, and early systemd may have had issues with
that. I'm considering LVM and ext4 again because I hope it's been long
enough that such issues have been worked out by now.
I mean, this is one of those areas where systemd has been outstanding,

Post by Bryan J Smith
and drastically improved over scripts. I.e., being more flexible, and
more deterministic, on calling all of the components needed to
properly shut down storage.
Especially when you have a lot of storage complexity, 20,000 paths, etc...
as I've been bitten by LVM not saving its metadata (e.g., resize

Post by Richard F. Ostrow Jr.
operation)
changes before.

Whoa, whoa, whoa! I'm not following you here at all.
LVM metadata is change at time of change -- such as a resize -- and
that's that. I mean, a LVM resize is virtually instantaneous! It's
just allocating more PEs from PVs assigned in the VG to the LEs of the
LV. Either you have the PEs, or you don't, and it's an extremely fast
Device Mapper operation that just updates the LVM meta-data when done.
Are you using "-r" with lvresize or something? I don't recommend it.
I would do a discrete "lvresize" and then a discrete "resize2fs." The
former is virtually instantaneous. The latter takes awhile, hence why
I never use "-r" with lvresize. But even then I don't see how "-r"
would cause issues, the LVM change "just happens" and it _should_
always be an O_DIRECT operation.

Wasn't using "-r", it was two discrete commands. It ran great until I
shutdown, at which point it lost its mind on startup. I got my "LVM failed
to stop" message from systemd while shutting down (which was normally
harmless on boots where I did _not_ change the metadata), but this time it
lost it. I lost a few months of TV recordings (I was expanding my RAID
array to accommodate new hard drives), which was inconvenient but not fatal.
Was this on a NAND device with discard enabled, but the device didn't

Post by Bryan J Smith
support it proper? That's the only time I think something like this
could ever occur.

Just a RAID-6 device with write-back enabled and barriers turned off
(battery backup on the card).
The only other time LVM writes to its meta is when it goes from active

Post by Bryan J Smith
to inactive, from use to clean. But even if you don't properly shut
down, then it shouldn't have any issue. But as Korbinator says,
that's what the backups are for, although they probably should be in
/boot instead of /etc.

If I go with LVM again, I'll definately make backups in /boot
It seems nobody actually uses the shutdown initrd from systemd, as I

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
can't find it anywhere with a google search (other than it exists, and that
it's designed to address this specific problem), and I've been unsuccessful
in attempting to set one up myself from just reading the documentation (I
just get a vague "FAILED" message on shutdown when attempting to start the
shutdown initrd service while shutting down).

Again, what distro is this?
And what kind of storage and/or other organization are you using?

Gentoo. At the time, I was using 12 1TB HDDs on an ARC-1231 RAID card in a
RAID-6 configuration (10 TB total) with GPT and no EFI. I am now using the
same card on 6 4 TB drives, still on a RAID-6 (16 TB total), running EFI
and GPT. I figure one day, 2.5" 4 TB HDDs may become affordable and I can
consider expanding this array, as I only have 2.5" slots left on the server.
The only thing I can think of is that you are using something that

Post by Bryan J Smith
doesn't have an entry/support in the shutdown, and prevents your VGs
from going inactive, because you don't have the support to unmount
file systems and do other things.
I.e., something gets "left open."

Not even sure where to look for something like that :(
But that still would _not_ explain why your LVM meta-data gets

Post by Bryan J Smith
corrupted. LVM meta-data operations -- which go to the reservation in
the PV itself -- are O_DIRECT, first journaled (LVM has its own), then
applied (to the official meta-data block). Other than the use/clean
for inactive/active, it's not going to be written to, and even that is
separate.
I've never seen this. An improper shutdown should _never_ affect LVM
meta-data. It's written explicitly _not_ to do such, via its journal
and the PV design.
There must be something else involved that's causing issues, and not
actually respecting O_DIRECT to the LVM meta-data in the PVs. That's
the only thing I could think of.

That's possible. The only thing I can point to LVM about on this is that
LVM was complaining on not being shutdown properly the last time it was
shut down after the metadata was changed, and on the next startup it was
unusable. It's possible that LUKS failed to update its metadata as it was
resized, or ext4 failed to update its metadata as it was resized... but I
only got the failure message for LVM.
-- bjs

Post by Bryan J Smith
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

--
Life without passion is death in disguise
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Bryan J Smith]

That's cool google voice to text for you ;-)

DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith - Technology Mercenary

Post by Bryan J Smith
Dude thats your problem right there the card must support you feed the you
feat post must be able to load the storage support not interrupt 13 by the
services if you have an older card it only has interrupt 13 de services
from the old 16 bit biased with out you please support with out a USB
storage target the compatibility support module CSM is going to load and be
in the legacy BIOS mode hence why you feed doesn't work you're not booting
into you feat and if you use GPT you'll have to use a BIOS boot partition
it won't be native
DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith - Technology Mercenary

Post by Richard F. Ostrow Jr.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
The closest I've come is an encrypted root with boot on a thumb drive
(removed after booting). I've encountered no issues related to dm-crypt and
the use of the whole disk. I'm not aware of anything that would allow /boot
to be located on an encrypted volume yet... but even if there was, this
system would not be capable of it, as my EFI firmware is incapable of seeing
my root drive device (the primary reason for the boot from thumb drive).

Executing efibootmgr with the proper information didn't add it to your
EFI firmware's bootable targets?
How about installing Rod Smith's rEFInd boot manager in the EFI System
Partition (ESP) and then having it 'find' and boot your Linux install,
irrespective of an EFI firmware entry for your Linux?

I haven't tried using efibootmgr directly, just grub2-install. I'm
installing onto a hardware RAID card that pre-dates EFI capabilities (Areca
ARC-1231), and when I was looking up the symptoms, it seemed that the
consensus was that EFI and older MS-DOS style RAID cards don't play well
together. The easy solution was to boot via EFI to a thumb drive and by the
time the kernel loads, the RAID card is initialized and ready to go.
I think if I were to set this system up again, I'd either try ZFS or go

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
back
to LVM and EXT4. If I were to go back to LVM/EXT4,

Not XFS?
Since you mentioned MythTV, I'd figure that'd be a no brainer. I
mean, SGI designed it purposely in the '90s for 64-bit video servers
with tens of TBs of files. Other than the 8KiB (MIPS) v. 4KiB (x86)
page size difference that had to be addressed in 2000 for the Linux
port, XFS has been relatively unchanged -- structurally -- since the
'90s. I'm biased because I've known Eric Sandeen et al. of the
[former] SGI XFS team a long time, but he's been guru #1 on Ext4 and
XFS (ergo, hacking Ext4 with lots of features that were long inherent
to XFS).

Yeah, I'm considering XFS as well, though I'm still leaning toward ZFS of
the three (more research may well change that - I'm not ready to convert
yet).
I'd appreciate any reliable resources on how to utilize a systemd shutdown

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
initrd for the purposes of properly releasing an LVM volume on shutdown,

Er, um, what? I've never had such an issue.
What distro and what is it doing ... or not doing ... on shutdown?
Did someone forget to load a module or other support?

This is a gentoo box. At the time I was running LVM, it was never able to
shutdown properly. I've seen some grumbling (let's call them rumors, since
it's been so long) that it may be because I was using LUKS on the bottom
layer, with LVM on top of it, and early systemd may have had issues with
that. I'm considering LVM and ext4 again because I hope it's been long
enough that such issues have been worked out by now.
I mean, this is one of those areas where systemd has been outstanding,

Post by Bryan J Smith
and drastically improved over scripts. I.e., being more flexible, and
more deterministic, on calling all of the components needed to
properly shut down storage.
Especially when you have a lot of storage complexity, 20,000 paths, etc...
as I've been bitten by LVM not saving its metadata (e.g., resize

Post by Richard F. Ostrow Jr.
operation)
changes before.

Whoa, whoa, whoa! I'm not following you here at all.
LVM metadata is change at time of change -- such as a resize -- and
that's that. I mean, a LVM resize is virtually instantaneous! It's
just allocating more PEs from PVs assigned in the VG to the LEs of the
LV. Either you have the PEs, or you don't, and it's an extremely fast
Device Mapper operation that just updates the LVM meta-data when done.
Are you using "-r" with lvresize or something? I don't recommend it.
I would do a discrete "lvresize" and then a discrete "resize2fs." The
former is virtually instantaneous. The latter takes awhile, hence why
I never use "-r" with lvresize. But even then I don't see how "-r"
would cause issues, the LVM change "just happens" and it _should_
always be an O_DIRECT operation.

Wasn't using "-r", it was two discrete commands. It ran great until I
shutdown, at which point it lost its mind on startup. I got my "LVM failed
to stop" message from systemd while shutting down (which was normally
harmless on boots where I did _not_ change the metadata), but this time it
lost it. I lost a few months of TV recordings (I was expanding my RAID
array to accommodate new hard drives), which was inconvenient but not fatal.
Was this on a NAND device with discard enabled, but the device didn't

Post by Bryan J Smith
support it proper? That's the only time I think something like this
could ever occur.

Just a RAID-6 device with write-back enabled and barriers turned off
(battery backup on the card).
The only other time LVM writes to its meta is when it goes from active

Post by Bryan J Smith
to inactive, from use to clean. But even if you don't properly shut
down, then it shouldn't have any issue. But as Korbinator says,
that's what the backups are for, although they probably should be in
/boot instead of /etc.

If I go with LVM again, I'll definately make backups in /boot
It seems nobody actually uses the shutdown initrd from systemd, as I

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
can't find it anywhere with a google search (other than it exists, and that
it's designed to address this specific problem), and I've been unsuccessful
in attempting to set one up myself from just reading the documentation (I
just get a vague "FAILED" message on shutdown when attempting to start the
shutdown initrd service while shutting down).

Again, what distro is this?
And what kind of storage and/or other organization are you using?

Gentoo. At the time, I was using 12 1TB HDDs on an ARC-1231 RAID card in
a RAID-6 configuration (10 TB total) with GPT and no EFI. I am now using
the same card on 6 4 TB drives, still on a RAID-6 (16 TB total), running
EFI and GPT. I figure one day, 2.5" 4 TB HDDs may become affordable and I
can consider expanding this array, as I only have 2.5" slots left on the
server.
The only thing I can think of is that you are using something that

Post by Bryan J Smith
doesn't have an entry/support in the shutdown, and prevents your VGs
from going inactive, because you don't have the support to unmount
file systems and do other things.
I.e., something gets "left open."

Not even sure where to look for something like that :(
But that still would _not_ explain why your LVM meta-data gets

Post by Bryan J Smith
corrupted. LVM meta-data operations -- which go to the reservation in
the PV itself -- are O_DIRECT, first journaled (LVM has its own), then
applied (to the official meta-data block). Other than the use/clean
for inactive/active, it's not going to be written to, and even that is
separate.
I've never seen this. An improper shutdown should _never_ affect LVM
meta-data. It's written explicitly _not_ to do such, via its journal
and the PV design.
There must be something else involved that's causing issues, and not
actually respecting O_DIRECT to the LVM meta-data in the PVs. That's
the only thing I could think of.

That's possible. The only thing I can point to LVM about on this is that
LVM was complaining on not being shutdown properly the last time it was
shut down after the metadata was changed, and on the next startup it was
unusable. It's possible that LUKS failed to update its metadata as it was
resized, or ext4 failed to update its metadata as it was resized... but I
only got the failure message for LVM.
-- bjs

Post by Bryan J Smith
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

--
Life without passion is death in disguise
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Bryan J Smith]

[ Okay, I'm now back on a real system ]

Post by Richard F. Ostrow Jr.
I haven't tried using efibootmgr directly, just grub2-install.

Then you're _not_ using uEFI. ;)

I have this conversation regularly. Unless you actually modify the
uEFI firmware to "target" the EFI System Partition (ESP), then you're
_not_ actually using uEFI at all.

I.e., there are three (3) ways to boot a modern system.

- uEFI w/CSM Storage to MBR (aka legacy BIOS/MS-DOS disk label)
- uEFI w/CSM Storage to GPT (w/type EF02h BIOS Boot Partition)
- uEFI Storage to GPT (w/type EF00h EFI System Partition)

The first two are _legacy_ 16-bit BIOS Int13h Disk Services via
Compatibility Support Module (CSM) Storage, instead of native, 64-bit
uEFI Storage services.

I.e., you're not using uEFI, even if your "base" firmware is.

The uEFI firmware "hands-off" to the CSM Storage, and it "boots" the
disk starting at the Master Boot Record (MBR). The MBR can either be
a native, legacy BIOS/MS-DOS disk label aka MBR Partition Table, or a
GUID Partition Table aka GPT disk label, with a special type EF02h
BIOS Boot Partition.

The latter "appears" to be a MBR from the standpoint of legacy 16-bit
BIOS Int13h Disk Services. Normally the MBR in GPT is a "read-only"
and "fake" MBR with a single partition and non-writeable, but the BIOS
Boot is used to emulate a MBR and legacy Primary partitions until the
kernel loads. Unfortunately the BIOS Boot Partition isn't an
universally compatible solution.

The CSM Storage would load "off-mainboard" and _legacy_ 16-bit BIOS
Int13h Disk Services, such as from your Areca. Hence why you're
booting legacy BIOS, and not uEFI at all.

Native 64-bit uEFI _never_ "boots the disk" or "loads a boot record."
It has "targets" in the firmware that tell it to load specific boot
loaders from the EFI System Partition (ESP). This is what confuses
most people, and how/why they dual-boot OSes and constantly run into
issues.

E.g., Windows installed in native uEFI mode and Linux installed in
legacy CSM Storage modes.

Post by Richard F. Ostrow Jr.
I'm installing onto a hardware RAID card that pre-dates EFI
capabilities (Areca ARC-1231), and when I was looking up
the symptoms, it seemed that the consensus was that EFI
and older MS-DOS style RAID cards don't play well together.

Again, native uEFI boot requires uEFI Storage. You cannot load a
legacy, off-firmware, 16-bit BIOS Int13h Disk Services firmware, and
boot native uEFI.

Although GPT _can_ be supported on any device ... as long as it's not
the booting device -- or -- is the booting device, but uses the BIOS
Boot Partition (type EF02h). In either case, it's legacy 16-bit BIOS
Int13h Disk Services at work, and not uEFI Storage.

Post by Richard F. Ostrow Jr.
The easy solution was to boot via EFI to a thumb drive and by the
time the kernel loads, the RAID card is initialized and ready to go.

But you're still having to use a solution to tell uEFI to "target" the
USB device, even if you're just using the default entry in your uEFI
implementation. In fact, it's not uncommon for the USB device to not
have an EFI System Partition (ESP), but do some other things.

Of course, your USB could be booting in a CSM too. Again, you _can_
have GPT ... as long as it's either not the booting device, or uses
the BIOS Boot Partition to "appear" to be a "writeable" MBR format
(whereas the GPT emulates a read-only MBR format without one).

Post by Richard F. Ostrow Jr.
Yeah, I'm considering XFS as well, though I'm still leaning toward ZFS of
the three (more research may well change that - I'm not ready to convert
yet).

My point was XFS _over_ Ext4 for video, as XFS was explicitly designed
by SGI for this "use case" from Day 1 in the mid '90s, and it excels
at it.

BTW, we've had this "context problem" in the past.

I.e., if you take my comments out-of-context, then of course, they
will not apply, and you are free to differ. But maybe that's your
intent? ;)

E.g., you brought up "Ext4" for video storage and I merely asked why
not "XFS"? Especially given Red Hat drives XFS development now, with
many of the former SGI maintainers.

Post by Richard F. Ostrow Jr.
This is a gentoo box. At the time I was running LVM, it was never able to
shutdown properly.

Then add that "context," and not just "systemd."

"I'm having a problem with systemd on Gentoo."

(glad I asked)

Post by Richard F. Ostrow Jr.
I've seen some grumbling (let's call them rumors, since
it's been so long) that it may be because I was using LUKS on the bottom
layer, with LVM on top of it, and early systemd may have had issues with
that. I'm considering LVM and ext4 again because I hope it's been long
enough that such issues have been worked out by now.

All I can say is that any distro that has adopted Dracut for its
initrd hasn't had a problem within 2 releases. And this is more than
just for Fedora/RHEL too.

Keep in mind that Dracut is a _modular_ initrd builder, designed to
take a lot of the "guess work" out of load ordering for an initrd.

E.g., before Dracut, I used to have to ensure certain HBAs, DM, MD,
etc... support was in the "proper order." Although the Fedora/RHEL
initrd (at the time) was fairly good about catching most things, I
still ran into a few situations (all Boot-from-SAN on RHEL5 --
pre-Dracut).

So, as I mentioned to Korbinator, I thought Gentoo was adopting
Dracut? I've seen it, and it's not quite "fully implemented," but it
should solve a lot of this non-sense.

Post by Richard F. Ostrow Jr.
Wasn't using "-r", it was two discrete commands. It ran great until I
shutdown, at which point it lost its mind on startup. I got my "LVM failed
to stop" message from systemd while shutting down (which was normally
harmless on boots where I did _not_ change the metadata), but this time it
lost it. I lost a few months of TV recordings (I was expanding my RAID array
to accommodate new hard drives), which was inconvenient but not fatal.

I don't know what to tell you. I don't have this problem, and I run
some pretty advanced storage -- both personally (MD) and, even more
so, with RHEL7 in Boot-from-SAN environments.

Post by Richard F. Ostrow Jr.
Just a RAID-6 device with write-back enabled and barriers turned off
(battery backup on the card).

Oh boy ... I'm not going to go there.

I.e., I could go deeper into this, but you have your assumptions.
E.g., "battery backup on the card"

In other words, this is a great area where I could go in deep, but
you'll just skip over it, like in the past. ;)

Furthermore, I don't understand why you want such on a storage device
that is far more read than write? I mean, why chance it?

So ... as cruel as this sounds (not my intent), I've been starting to
say it even professionally the last 5 years ... "You deserve what you
get."

Usually I see people say similar about journaling (let alone only
meta-data journaling). And more and more with NAND storage too.

(lots of face palms in not just e-mail threads, but face palms too)

Post by Richard F. Ostrow Jr.
Gentoo. At the time, I was using 12 1TB HDDs on an ARC-1231
RAID card in a RAID-6 configuration (10 TB total) with GPT and
no EFI.

Right, because you're booting from USB.

Post by Richard F. Ostrow Jr.
I am now using the same card on 6 4 TB drives, still on a RAID-6
(16 TB total), running EFI and GPT.

(face palm)

Please don't use that phrase when it's not technically accurate.

Post by Richard F. Ostrow Jr.
I figure one day, 2.5" 4 TB HDDs may become affordable and I can
consider expanding this array, as I only have 2.5" slots left on the server.
Not even sure where to look for something like that :(

I don't know ... journald perhaps?

I.e., unlike syslog, journald captures 100% of _all_ logs.

That's part of its "overload" problem too (but not the first to deal with it)

Post by Richard F. Ostrow Jr.
That's possible.

Actually, I know _exactly_ why (now).

You're using writeback without barriers and probably some other settings. ;)

Post by Richard F. Ostrow Jr.
The only thing I can point to LVM about on this is that LVM
was complaining on not being shutdown properly the last time it was shut
down after the metadata was changed, and on the next startup it was
unusable. It's possible that LUKS failed to update its metadata as it was
resized, or ext4 failed to update its metadata as it was resized... but I
only got the failure message for LVM.

See the aforementioned.

There's a reason I don't f' with such things when I want to ensure
O_DIRECT. But then again, I've been through the kernel VFS code. And
I also understand how "commits" actually work through the Intel
X-scale reference RAID design and how NCQ/ATA works too, irrespective
of OS.

I.e., I would get away from writeback and lack of barriers. Speaking
from deep understanding and experience.

-- bjs

[Richard F. Ostrow Jr.]

Post by Bryan J Smith
[ Okay, I'm now back on a real system ]

Post by Richard F. Ostrow Jr.
I haven't tried using efibootmgr directly, just grub2-install.

Then you're _not_ using uEFI. ;)
I have this conversation regularly. Unless you actually modify the
uEFI firmware to "target" the EFI System Partition (ESP), then you're
_not_ actually using uEFI at all.
I.e., there are three (3) ways to boot a modern system.
- uEFI w/CSM Storage to MBR (aka legacy BIOS/MS-DOS disk label)
- uEFI w/CSM Storage to GPT (w/type EF02h BIOS Boot Partition)
- uEFI Storage to GPT (w/type EF00h EFI System Partition)
The first two are _legacy_ 16-bit BIOS Int13h Disk Services via
Compatibility Support Module (CSM) Storage, instead of native, 64-bit
uEFI Storage services.
I.e., you're not using uEFI, even if your "base" firmware is.
The uEFI firmware "hands-off" to the CSM Storage, and it "boots" the
disk starting at the Master Boot Record (MBR). The MBR can either be
a native, legacy BIOS/MS-DOS disk label aka MBR Partition Table, or a
GUID Partition Table aka GPT disk label, with a special type EF02h
BIOS Boot Partition.
The latter "appears" to be a MBR from the standpoint of legacy 16-bit
BIOS Int13h Disk Services. Normally the MBR in GPT is a "read-only"
and "fake" MBR with a single partition and non-writeable, but the BIOS
Boot is used to emulate a MBR and legacy Primary partitions until the
kernel loads. Unfortunately the BIOS Boot Partition isn't an
universally compatible solution.
The CSM Storage would load "off-mainboard" and _legacy_ 16-bit BIOS
Int13h Disk Services, such as from your Areca. Hence why you're
booting legacy BIOS, and not uEFI at all.
Native 64-bit uEFI _never_ "boots the disk" or "loads a boot record."
It has "targets" in the firmware that tell it to load specific boot
loaders from the EFI System Partition (ESP). This is what confuses
most people, and how/why they dual-boot OSes and constantly run into
issues.
E.g., Windows installed in native uEFI mode and Linux installed in
legacy CSM Storage modes.

I'll not comment on this beyond stating that this system does not
support CSM, because we've beaten this to death in previous
conversations and got nowhere. The proof is in the pudding, my
/sys/firmware/efi/vars is populated, which is not possible when booting
from CSM or legacy BIOS. Luckily, this is not a uEFI issue, so maybe we
can talk about it.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
Yeah, I'm considering XFS as well, though I'm still leaning toward ZFS of
the three (more research may well change that - I'm not ready to convert
yet).

My point was XFS _over_ Ext4 for video, as XFS was explicitly designed
by SGI for this "use case" from Day 1 in the mid '90s, and it excels
at it.
BTW, we've had this "context problem" in the past.
I.e., if you take my comments out-of-context, then of course, they
will not apply, and you are free to differ. But maybe that's your
intent? ;)
E.g., you brought up "Ext4" for video storage and I merely asked why
not "XFS"? Especially given Red Hat drives XFS development now, with
many of the former SGI maintainers.

I'm afraid I'm not following you here at all. I simply said I was
considering the three, and that I would research more into it later.
Where's the "context problem?"

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
Just a RAID-6 device with write-back enabled and barriers turned off
(battery backup on the card).

Oh boy ... I'm not going to go there.
I.e., I could go deeper into this, but you have your assumptions.
E.g., "battery backup on the card"
In other words, this is a great area where I could go in deep, but
you'll just skip over it, like in the past. ;)
Furthermore, I don't understand why you want such on a storage device
that is far more read than write? I mean, why chance it?
So ... as cruel as this sounds (not my intent), I've been starting to
say it even professionally the last 5 years ... "You deserve what you
get."
Usually I see people say similar about journaling (let alone only
meta-data journaling). And more and more with NAND storage too.
(lots of face palms in not just e-mail threads, but face palms too)

So without going into detail, when Areca says they guarantee that all
data that reaches the card will be recorded, even in the event of a
power failure (with the use of the battery backup), you're saying that
their guarantee is worthless? Or, more to the point... not just Areca,
but any vendor that makes such a guarantee, because the concept itself
it somehow flawed? * Note, I've just done some reading [1] that supports
your argument (which makes me wonder why I purchased my BBU), but it
only supports it in the case of an unclean shutdown. This problem
surfaced on a normal, "clean" shutdown (with the exception of LVM not
being able to release).

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
The only thing I can point to LVM about on this is that LVM
was complaining on not being shutdown properly the last time it was shut
down after the metadata was changed, and on the next startup it was
unusable. It's possible that LUKS failed to update its metadata as it was
resized, or ext4 failed to update its metadata as it was resized... but I
only got the failure message for LVM.

See the aforementioned.
There's a reason I don't f' with such things when I want to ensure
O_DIRECT. But then again, I've been through the kernel VFS code. And
I also understand how "commits" actually work through the Intel
X-scale reference RAID design and how NCQ/ATA works too, irrespective
of OS.
I.e., I would get away from writeback and lack of barriers. Speaking
from deep understanding and experience.
-- bjs

I accept that. I'm re-enabling barriers and turning off my write-back as
I write this, as I can see where it can introduce serious problems in
the event of a crash or a power failure (even with the BBU). But...
again, it doesn't explain what happened previously, as that was
supposedly a "clean" shutdown.

[1] - http://monolight.cc/2011/06/barriers-caches-filesystems/

[Bryan J Smith]

Post by Richard F. Ostrow Jr.
I've been using dracut for quite a while now under gentoo,
and I was using it back then when I had these issues as
well.

While dracut is not a guarantee, and it's still a "modular" system to
allow for various logic, support, etc..., it does enable such
ordering. It's up to the distro to implement it correctly.

Post by Richard F. Ostrow Jr.
It did everything my manual scripts did, and it did it while
following the appropriate standards. It also was a whole lot
easier to maintain, and worked when my scripts started
failing when LVM changed its initrd requirements.

Define "LVM changed its initrd requirements"?

I haven't seen any "change" in LVM ... unless you mean the old (over a
decade) change from LVMv1 in kernel 2.4 to Device Mapper-based LVMv2
(DM-LVM2) in kernel 2.6+.

Post by Richard F. Ostrow Jr.
Sounded like a win-win to me. The only downside is it wasn't quite
as "minimal" as my scripts were...

Okay, I guess that's where I go "face palm."

As a long-time Gentoo lover, _nothing_ is more distracting and, in
many cases, just _wrong_ of an attitude than either the argument of
"minimal" or "optimized." It's kinda like when people say "systemd is
for speeding up boot-times" when systemd was _never_ designed to do
such, but there _can_ be -- although it's largely a legacy argument by
Upstart (which systemd only "claims" because of that past Upstart
"marketing").

So ... I'll use my long-stnading, classic "Ricer v. Corvette" argument.

Sure, you can drop a lot of money into a "Ricer" and tune the heck out
of it. And you can think you're "cool." But there's still the
realities of ...

- You've spend far _more_ than a Corvette
- You're still accelerating a lot _slower_ than a Corvette**
- You're still handling far _worse_ than a Corvette
- You're getting far _worse_ gas mileage than a Corvette
- You still do a lot of things _worse_ than Corvette (especially torque)
- Etc...

**I'll make an exception for Nitrous v. non-Nitrous, although a
Nitrous Corvette is unreal ... especially with the overhead GM gives
the LS series of engines (to reach 100K mile warranties).

Heck, even the new, supercharged C7 Z06 doesn't even have a gas
guzzler tax (with manual transmission), while the Genesis R Spec gets
worse gas mileage, but "plays games" to avoid it (something Hyundai
has had to revise in the past, and has paid fines for).

So ... please excuse me if the "minimal" argument doesn't go very far
with me, just like the "optimized" argument too.

I.e., you're limiting yourself and causing yourself headaches for
often _0_ benefit, or even _reduced_ performance. ;)

Post by Richard F. Ostrow Jr.
but it worked after every kernel/LVM/{other initrd-necessary binary}
update, so it was worth it as far as I was concerned.

Indeed. Dracut provides a modular framework to solve most issues.

In fact, when I cannot get Gentoo, Ubuntu LTS, etc... to
Boot-from-SAN, the first thing I do is look at the Dracut
implementation, and then attempt to merge over the Fedora-RHEL
additions.

Post by Richard F. Ostrow Jr.
Absolutely agree, although I'll admit I can never remember that parameter
without looking it up. It's really something worth memorizing.

The "breakpoints" are left up to the initrd itself, so they cannot be
well documented in ... say .. a manpage. However, just throwing
"rd.break" with no options means it drops to the shell after the
initrd is complete.

I use it regularly.

Post by Richard F. Ostrow Jr.
I'll not comment on this beyond stating that this system does not
support CSM,

Compatibility Support Modules (CSMs) are included in _all_ uEFI
implementations. You can boot uEFI, but load a CSM for a specific
subsystem -- like the Storage CSM. It depends on what "functions" the
vendor puts into the firmware that the user can modify and/or enable.

Case-in-point ... without _some_ CSM solutions, some systems would not
work at all. E.g., Video CSM for most video cards.

Post by Richard F. Ostrow Jr.
because we've beaten this to death in previous conversations and got
nowhere. The proof is in the pudding, my /sys/firmware/efi/vars is
populated, which is not possible when booting from CSM

That is a 100% _false_ statement.

Post by Richard F. Ostrow Jr.
or legacy BIOS.

This is the _only_ true portion.

uEFI is uEFI, and it's there, _even_ if you booted in another mode,
loading the Storage CSM so it had to use MBR or a GPT w/BIOS Boot
Partition ... or an USB boot sector, etc...

Post by Richard F. Ostrow Jr.
Luckily, this is not a uEFI issue, so maybe we can talk about it.

Hey man ... _you_ decided to respond to _my_ original context by
asking about systemd in a completely different context that was
well-off the subject and, more importantly, posted with incomplete
information.

I cannot help it if you overly complicate your system and do all sorts
of things out of arguments of "minimal" or "should work" or other
things, and then ask how to "fix systemd" and other things for your
implementation.

I deal with multi-petabytes of data daily, so i don't f' around with
enabling things.

Heck, I don't just blindly enable "discard" either -- without testing
the NAND device, even if the device is already fine, but just had a
firmware update. I don't trust NAND firmware to handle things
correctly, and always re-test after any firmware update.

Post by Richard F. Ostrow Jr.
I'm afraid I'm not following you here at all. I simply said I was
considering the three, and that I would research more into it later. Where's
the "context problem?"

You didn't include XFS at all ... only after I mentioned it.

And I only mentioned it in the context of "better than Ext4," nothing
else. I didn't try to revisit BTRFS or ZFS, just XFS against Ext4.
You had omitted XFS and were only talking about Ext4.

As before ... you entered this thread. I hadn't "baited" you.

Post by Richard F. Ostrow Jr.
So without going into detail, when Areca says they guarantee that
all data that reaches the card will be recorded, even in the event
of a power failure (with the use of the battery backup), you're
saying that their guarantee is worthless?

Let's see here ...

I have been under NDA with Intel, including over the X-Scale used as a
RAID card with their (Intel's) firmware, including working with no
less than two (2) OEMs in the mid '00s. This isn't just via Red Hat
(which included other work with Intel under NDA), but TimeSys (one of
only two embedded Linux vendors at the time). I've seen the code, and
I understand the architecture.

I.e., you're grossly misapplying it. But IT people do that all-the-time.

There is no magic bullet to get hardware to cause an OS to do
everything it wants, it's vice-versa.

E.g., the Areca driver cannot tell the Linux VFS or Device Mapper code
how to behave, when to commit, etc...

Post by Richard F. Ostrow Jr.
Or, more to the point... not just Areca, but any vendor that
makes such a guarantee, because the concept itself it somehow
flawed? *

Your application is flawed.

The Areca driver has no control over the Linux VFS, DeviceMapper,
etc... subsystems.

Post by Richard F. Ostrow Jr.
Note, I've just done some reading [1] that supports your argument
(which makes me wonder why I purchased my BBU),

Because you don't understand the purpose of the Battery Backup Unit
(BBU), and how it's only going to affect what reaches the card. ;)

Same goes for any NVRAM design.

I.e., it can only impact the subsystems it can target, not those that
are targeting it. ;)

E.g., right now people are blowing GM's new Supercharged LT4 engine in
the C7 Z06 because they are overriding their ECU to prevent it from
reducing performance related to thermal management.

Post by Richard F. Ostrow Jr.
but it only supports it in the case of an unclean shutdown.
This problem surfaced on a normal, "clean" shutdown
(with the exception of LVM not being able to release).

Dude ... I don't know what to say other than "Congrats!"

I.e., you just took yourself on a full tour of how you did _not_
shutdown "clean." ;)

Post by Richard F. Ostrow Jr.
I accept that. I'm re-enabling barriers and turning off my write-back as I
write this, as I can see where it can introduce serious problems in the
event of a crash or a power failure (even with the BBU).

Okay, that's a start.

Just understand I'm a "nice guy." But when you start instigating
situations, and turn around and make claims that are not true, at some
point, I'm going to let you take yourself on a tour of the folly, and
try to point it out.

I appreciate your candor and honesty, so I don't want that to go
unnoticed. But I'm still "bothered" by your statements about Areca
(which is from Intel's reference design and RAID firmware), because
you're still misapplying it.

I.e., I've been "thrown under the bus" as a "vendor consultant" or
"vendor enablement tech," only to have to document the issues and, in
the end, prove it was the customer tech that utterly did irresponsible
things.

I don't like being in those situations, because _no_one_ wins. Of
course, don't be with another vendor when you do this, because I will
get you laughed out of the room ... and your contract not renewed.

I can be your friend ... or the documentor of your worst practices,
especially when you force me to do the latter because you keep making
statements and rationales for doing something irresponsible with my
vendor's product.

There are several companies several billion dollars short because of
me ... personally, or should I say, with the utmost, professional
restraint, but required, eventual disclosure.

Post by Richard F. Ostrow Jr.
But... again, it doesn't explain what happened previously,
as that was supposedly a "clean" shutdown.

Because ... it wasn't. ;)

Post by Richard F. Ostrow Jr.
[1] - http://monolight.cc/2011/06/barriers-caches-filesystems/

The reason I'm most trusting of Red Hat in the Linux base is because ...

A) They have the most maintainers on several file systems, and ...
B) They don't support a file system unless they are ready to back it

Now I've long complained about Red Hat taking forever to adopt XFS,
but at least they did. But they continue to _not_ support BTRFS,
despite the sheer Upstream work they've done on it (since Oracle's
large departure from it).

As far as ZFS -- on Linux -- that's a whole other ballgame.

-- bjs

[Steve Litt]

On Sun, 9 Aug 2015 12:36:53 -0400

Post by Bryan J Smith
As a long-time Gentoo lover, _nothing_ is more distracting and, in
many cases, just _wrong_ of an attitude than either the argument of
"minimal" or "optimized." It's kinda like when people say "systemd is
for speeding up boot-times" when systemd was _never_ designed to do
such, but there _can_ be -- although it's largely a legacy argument by
Upstart (which systemd only "claims" because of that past Upstart
"marketing").
So ... I'll use my long-stnading, classic "Ricer v. Corvette"
argument.
Sure, you can drop a lot of money into a "Ricer" and tune the heck out
of it. And you can think you're "cool." But there's still the
realities of ...
- You've spend far _more_ than a Corvette
- You're still accelerating a lot _slower_ than a Corvette**
- You're still handling far _worse_ than a Corvette
- You're getting far _worse_ gas mileage than a Corvette
- You still do a lot of things _worse_ than Corvette (especially torque)
- Etc...

Let's open up the analogy to also include my old 1959 Plymouth, and
forget about gas mileage, because there's no analogy I can see to that
on computers (except heat and electricity, but these go up with cpu
usage and hardware, not with increasing age of software)

* My 59 Plymouth has a flathead 6 I can tune up in 20 minutes with an
adjustible wrench, a pliers, a screwdriver, and a gapping tool. The
spark plugs are right on top of the engine.

* Replacing my thermostat on my 59 Plymouth is a 30 minute job *in a
parking lot*, not a garage. Screwdriver, adj wrench, and knife to
scrape off the old gasket.

* Plenty of room in the engine compartment to get in and do the job.

* Almost nothing is buried. What's buried isn't buried under much.

* Transmission is nothing but manual links: When they get stuck, you
just reach in and pull on them to free everything up.

* Gas tank replacement: 45 minutes removing one from a junkyard car, 45
minutes putting it on yours, *in the street*. This was the ugliest
job I ever did on this car, but don't try it at home with your riced
up Honda or your Corvette.

* 0 to 60 in 20 seconds, which is perfectly acceptable if you know how
to merge decently.

My 59 Plymouth was minimalist. It's ugly. The seats are ripped so it's
like going on a hay ride. The radio works only one day in three. And
had I had the knowledge I have today, there was probably *nothing* I
couldn't have fixed on that car, myself, with not too many tools.

Today I have a 2012 Jeep. Everything crammed in. Everything
interdependent. I bet when I shift gears it tells the computer, and the
computer actuates the proper solonoids. A cracker can remote drive my
Jeep. The most complex repair I'd do on this car is to fill the wiper
fluid.

Of course, my 59 Plymouth probably got 12MPG, and my Jeep gets 23 in
the city, 28 on the highway, and my Plymouth smoked up every area it
touched, so I couldn't use it today. But there's no direct analogy to
gas mileage and pollution with computers.

A couple nights ago I worked with an OS called Void Linux, but it might
as well have been called 59 Plymouth. So simple I understood everything
about it, and could have fixed anything with an adjustable wrench, a
screwdriver and Vim.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

Post by Steve Litt
Let's open up the analogy to also include my old 1959 Plymouth,

Sure.

In fact, one could argue that Intel selling its X-Scale to Marvell and
going with "Stealy" would kinda be like GM chucking the 4th Generation
Corvette, and going back to a '56 Chevy.

Post by Steve Litt
and forget about gas mileage, because there's no analogy I can
see to that on computers (except heat and electricity, but these
go up with cpu usage and hardware,

O'RLY?

I see x86 dead by 2020, with ARM taking over. But that's another story.

Post by Steve Litt
not with increasing age of software)

Hardware is software today, not just microcode, but translation too.

Post by Steve Litt
* My 59 Plymouth has a flathead 6 I can tune up in 20 minutes with an
adjustible wrench, a pliers, a screwdriver, and a gapping tool. The
spark plugs are right on top of the engine.
* Replacing my thermostat on my 59 Plymouth is a 30 minute job *in a
parking lot*, not a garage. Screwdriver, adj wrench, and knife to
scrape off the old gasket.

In other words ... you want BSD, not GNU/Linux.

Post by Steve Litt
* Plenty of room in the engine compartment to get in and do the job.

That rules out Android, software-wise. ;)

Hardware-wise, A57 is going to enable AMD to make Intel irrelevant.

Post by Steve Litt
* Almost nothing is buried. What's buried isn't buried under much.

I agree with you hear. The ECU changed cars forever.

And with manufacturers being chronically, if not criminally, negligent
with _not_ separating entertainment control systems from important
ones, it's getting very, very scary.

Post by Steve Litt
* Transmission is nothing but manual links: When they get stuck, you
just reach in and pull on them to free everything up.

I'm with you there. I still trust manual transmissions.

Of course, I "cheat." Rev matching is just too good not to use. ;)

Post by Steve Litt
* Gas tank replacement: 45 minutes removing one from a junkyard
car, 45 minutes putting it on yours, *in the street*. This was the
ugliest job I ever did on this car, but don't try it at home with your
riced up Honda or your Corvette.

Corvettes have been too much software for over a decade now.

Of course, even when you have something 100% manual -- like the
emergency door release that is bright red -- you still have people who
don't look for something, and die of heat exposure in their car.

Especially with over 50% of the US' Corvettes having Florida tags.

Post by Steve Litt
* 0 to 60 in 20 seconds, which is perfectly acceptable if you know how
to merge decently.

But not to overlook a nod to those vehicles of yesteryear ...

I'll take a 50 year-old turbine powered car against any "ricer" today. ;)

Post by Steve Litt
My 59 Plymouth was minimalist. It's ugly. The seats are ripped so it's
like going on a hay ride.

Yeah, but you've got plenty of room to "get lucky," just like in a hay
ride too. ;)

Post by Steve Litt
The radio works only one day in three.

Well ... that _can_ be addressed with an "upgrade," even adding
Bluetooth, by a low-paid Best Buy tech and a few hundred bucks for the
radio on-sale.

Post by Steve Litt
And had I had the knowledge I have today, there was probably
*nothing* I couldn't have fixed on that car, myself, with not too
many tools.

Which is like BSD. I love me some BSD.

BSD is like Cynthia Myers. No matter what generation you are, you'd
so hit it and love every moment of it. Simple, uncommon beauty is
always appreciated out-of-time.

Post by Steve Litt
Today I have a 2012 Jeep. Everything crammed in. Everything
interdependent. I bet when I shift gears it tells the computer, and the
computer actuates the proper solonoids. A cracker can remote drive my
Jeep. The most complex repair I'd do on this car is to fill the wiper
fluid.

Actually, Jeep Patriots have CVTs, because they are a low-enough
torque application to work, and work well.

I had an original 2007 1/2 Jeep Patriot with the CVT2 and the 19:1
gear ratio. People made fun of me ... until I gave them a ride while
they were stuck on I-97 during DC's "Snowpocalypse" a few years back.

Post by Steve Litt
Of course, my 59 Plymouth probably got 12MPG, and my Jeep gets 23 in
the city, 28 on the highway, and my Plymouth smoked up every area it
touched, so I couldn't use it today. But there's no direct analogy to
gas mileage and pollution with computers.

Sorry, but x86-64 v. ARMv8 is already starting.

Post by Steve Litt
A couple nights ago I worked with an OS called Void Linux, but it might
as well have been called 59 Plymouth. So simple I understood everything
about it, and could have fixed anything with an adjustable wrench, a
screwdriver and Vim.

Slackware had its day. Gentoo also seems to get away from its roots,
and doesn't do it well.

But BSD and its ports will live forever. Kinda like Cynthia Myers was
still broadly popular at the time of her passing in 2011, despite most
people not knowing who she was, like those don't recognize how much
BSD they rely on.

-- bjs

[Steve Litt]

On Sun, 9 Aug 2015 13:33:42 -0400

Post by Bryan J Smith
Actually, Jeep Patriots have CVTs, because they are a low-enough
torque application to work, and work well.

Mine has a 5 on the floor with a clutch, which I consider fortunate,
given that it's underpowered with a 2.0 liter engine. Getting on a
crowded freeway, I can rev that puppy to 5K, going 45 in 2nd gear and
over 60 in 3rd gear. Which is the only way I could safely get on a
crowded freeway.

Of course, I've never used a CVT, so for all I know they have ways of
accellerating with the engine spinning between 5K and 6K.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

Post by Steve Litt
Mine has a 5 on the floor with a clutch, which I consider fortunate,
given that it's underpowered with a 2.0 liter engine. Getting on a
crowded freeway, I can rev that puppy to 5K, going 45 in 2nd gear and
over 60 in 3rd gear. Which is the only way I could safely get on a
crowded freeway.

You obviously haven't driven a CVT. ;)

I got threatened with jailtime (not that I didn't see through that
"scare tactic") by an ignorant cop who didn't realize my CVT2 had
kicked in a very high ratio when I started up an incline. He thought
I was rev'ing my engine, when it was merely the Jeep switching into a
19:1 gear ratio.

Post by Steve Litt
Of course, I've never used a CVT, so for all I know they have ways of
accellerating with the engine spinning between 5K and 6K.

Continually Variable Transmission (CVT). It doesn't "shift" into a
lower gear, it "spins up" into it higher ratio. ;)

It's one of the things I miss about my 2007 1/2 Jeep Patriot and its
CVT2 with the 19:1 option. Of course, that brought it's highway
mileage down to 23mpg from 28mpg, because there was no overdrive, and
it sucked beyond 60mph.

-- bjs

[Steve Litt]

On Sun, 9 Aug 2015 14:29:06 -0400

Post by Bryan J Smith

Post by Steve Litt
Mine has a 5 on the floor with a clutch, which I consider fortunate,
given that it's underpowered with a 2.0 liter engine. Getting on a
crowded freeway, I can rev that puppy to 5K, going 45 in 2nd gear
and over 60 in 3rd gear. Which is the only way I could safely get
on a crowded freeway.

You obviously haven't driven a CVT. ;)

Never. When I buy a used car, I spend less than $5K, so nothing new
enough to have a CVT is both available and running. When I bought my
one and only new car, I wanted a manual transmission, because:

A: I wanted one

B: I'm having a midlife crisis

C: I miss my 59 Plymouth


SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

My Daily Driver is a '10 Cobalt XFE that is completely manual. OnStar
cannot control anything in it. It was the last GM ever made without hooks
into the vehicle control system for OnStar.

It had friends in DC that made fun of me when I bought it. Of course, it's
nearing 50K now, and cost me only $10.3K brand new. It has a tall 1st
gear, a flywheel and a long overdrive that gets 42mpg at 60mph, and still
37mpg at 80mph.

That's because it actually has a 2.2L, and not a dinky 1.4-1.8L like most
economies that can't get their good gas mileage at 80mph.

Heck, my '09 C6 gets 35mpg at 60mph, 30 at 80mph and doesn't "drop" to the
EPA estimated of 26mpg until I'm doing 100mph. Don't understand how the
EPA and GM test at all.

They must have lead foots or take the top off.

-- bjs

DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith - Technology Mercenary

Post by Steve Litt
On Sun, 9 Aug 2015 14:29:06 -0400

Post by Bryan J Smith

Post by Steve Litt
Mine has a 5 on the floor with a clutch, which I consider fortunate,
given that it's underpowered with a 2.0 liter engine. Getting on a
crowded freeway, I can rev that puppy to 5K, going 45 in 2nd gear
and over 60 in 3rd gear. Which is the only way I could safely get
on a crowded freeway.

You obviously haven't driven a CVT. ;)

Never. When I buy a used car, I spend less than $5K, so nothing new
enough to have a CVT is both available and running. When I bought my
A: I wanted one
B: I'm having a midlife crisis
C: I miss my 59 Plymouth
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Shawn McMahon]

Now go try to get a job fixing cars. Ask them how often their customers
have a '59 Plymouth, and how often a '12 Jeep.

Post by Steve Litt
On Sun, 9 Aug 2015 12:36:53 -0400

Post by Bryan J Smith
As a long-time Gentoo lover, _nothing_ is more distracting and, in
many cases, just _wrong_ of an attitude than either the argument of
"minimal" or "optimized." It's kinda like when people say "systemd is
for speeding up boot-times" when systemd was _never_ designed to do
such, but there _can_ be -- although it's largely a legacy argument by
Upstart (which systemd only "claims" because of that past Upstart
"marketing").
So ... I'll use my long-stnading, classic "Ricer v. Corvette" argument.
Sure, you can drop a lot of money into a "Ricer" and tune the heck out
of it. And you can think you're "cool." But there's still the
realities of ...
- You've spend far _more_ than a Corvette
- You're still accelerating a lot _slower_ than a Corvette**
- You're still handling far _worse_ than a Corvette
- You're getting far _worse_ gas mileage than a Corvette
- You still do a lot of things _worse_ than Corvette (especially torque)
- Etc...

Let's open up the analogy to also include my old 1959 Plymouth, and
forget about gas mileage, because there's no analogy I can see to that
on computers (except heat and electricity, but these go up with cpu
usage and hardware, not with increasing age of software)
* My 59 Plymouth has a flathead 6 I can tune up in 20 minutes with an
adjustible wrench, a pliers, a screwdriver, and a gapping tool. The
spark plugs are right on top of the engine.
* Replacing my thermostat on my 59 Plymouth is a 30 minute job *in a
parking lot*, not a garage. Screwdriver, adj wrench, and knife to
scrape off the old gasket.
* Plenty of room in the engine compartment to get in and do the job.
* Almost nothing is buried. What's buried isn't buried under much.
* Transmission is nothing but manual links: When they get stuck, you
just reach in and pull on them to free everything up.
* Gas tank replacement: 45 minutes removing one from a junkyard car, 45
minutes putting it on yours, *in the street*. This was the ugliest
job I ever did on this car, but don't try it at home with your riced
up Honda or your Corvette.
* 0 to 60 in 20 seconds, which is perfectly acceptable if you know how
to merge decently.
My 59 Plymouth was minimalist. It's ugly. The seats are ripped so it's
like going on a hay ride. The radio works only one day in three. And
had I had the knowledge I have today, there was probably *nothing* I
couldn't have fixed on that car, myself, with not too many tools.
Today I have a 2012 Jeep. Everything crammed in. Everything
interdependent. I bet when I shift gears it tells the computer, and the
computer actuates the proper solonoids. A cracker can remote drive my
Jeep. The most complex repair I'd do on this car is to fill the wiper
fluid.
Of course, my 59 Plymouth probably got 12MPG, and my Jeep gets 23 in
the city, 28 on the highway, and my Plymouth smoked up every area it
touched, so I couldn't use it today. But there's no direct analogy to
gas mileage and pollution with computers.
A couple nights ago I worked with an OS called Void Linux, but it might
as well have been called 59 Plymouth. So simple I understood everything
about it, and could have fixed anything with an adjustable wrench, a
screwdriver and Vim.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Bryan J Smith]

Post by Shawn McMahon
Now go try to get a job fixing cars.
Ask them how often their customers have
a '59 Plymouth, and how often a '12 Jeep.

Crap, I cannot even find a good Corvette tech at GM dealers these
days. Heck, I'd settle for just "common sense."

I.e., recently both my father and then even I failed to get a GM
dealer's tech to understand how any recent Corvette generation cannot
have its tires "rotated."

That was pretty much the end of that service appointment attempt. No
less than three (3) GM dealers in town we don't have service our C7
and C6, respectively.

-- bjs

[Steve Litt]

On Sun, 9 Aug 2015 14:02:46 -0400

Post by Shawn McMahon
Now go try to get a job fixing cars. Ask them how often their
customers have a '59 Plymouth, and how often a '12 Jeep.

And with a single sentence, Shawn has gotten to the heart of the
matter: It depends on your situation.

If I were making my living fixing operating systems, I sure wouldn't
specialize in Void Linux, the 59 Plymouth equivalent, because:

1) Few use it

2) It's simple enough that people fix it themselves.

If I were repairing OS's, I'd specialize in widely used,
complex OS's like Red Hat, Debian, Ubuntu, etc. More difficult to fix
it right means more money for me.

But I don't make my living fixing operating systems. I use an operating
system as a tool in making my living. When my OS breaks, I need the
ability to fix it. My company's fanances don't allow bringing in a
hired gun at $60/hr, and besides, it's often difficult to find someone
who's good enough to fix the root cause instead of doing a hack job
whose side effects bite me somewhere else. As the old saying goes, if
you want it done right, do it yourself. This is especially important if
you're not a company big enough to scale tens or hundreds of servers to
one admin.

If Troubleshooters.Com were as big as Fedex, I'd specify a widely
used OS, not Void. Probably not even Gentoo. Because it's difficult to
find Void specialists, or even (perhaps *especially*) Gentoo
specialists.

So at what point would I switch over from something like Void or Gentoo
to something like Debian or RedHat or Ubuntu or SuSE? I'd say when I
get up to between 3 to 5 admins, and it starts getting too hard to
recruit more from the local community college and train them in Void.

Minimal systems are wonderful for small businesses with tech chops.
They're lousy for those making a living administering or repairing
computer systems. As a business who uses the software gets bigger, the
attraction of minimal systems starts getting less.

Notwithstanding what was said in my preceding paragraph, I think a lot
of businesses' acceptance of the new complexity was as much due to
their lack of knowledge of the alternatives as it was to actual
improvements the complexity brings to their businesses.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

I'd just run BSD instead of GNU/Linux.

This "minimalist" farce is really maximum, unsupportable spaghetti, and
results in constantly breaking systems. Why?

Because the "minimalists" don't understand what all is involved, and miss a
lot of things. Which is why they shouldn't be on GNU/Linux.

But BSD.

-- bjs

DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith - Technology Mercenary

Post by Steve Litt
On Sun, 9 Aug 2015 14:02:46 -0400

Post by Shawn McMahon
Now go try to get a job fixing cars. Ask them how often their
customers have a '59 Plymouth, and how often a '12 Jeep.

And with a single sentence, Shawn has gotten to the heart of the
matter: It depends on your situation.
If I were making my living fixing operating systems, I sure wouldn't
1) Few use it
2) It's simple enough that people fix it themselves.
If I were repairing OS's, I'd specialize in widely used,
complex OS's like Red Hat, Debian, Ubuntu, etc. More difficult to fix
it right means more money for me.
But I don't make my living fixing operating systems. I use an operating
system as a tool in making my living. When my OS breaks, I need the
ability to fix it. My company's fanances don't allow bringing in a
hired gun at $60/hr, and besides, it's often difficult to find someone
who's good enough to fix the root cause instead of doing a hack job
whose side effects bite me somewhere else. As the old saying goes, if
you want it done right, do it yourself. This is especially important if
you're not a company big enough to scale tens or hundreds of servers to
one admin.
If Troubleshooters.Com were as big as Fedex, I'd specify a widely
used OS, not Void. Probably not even Gentoo. Because it's difficult to
find Void specialists, or even (perhaps *especially*) Gentoo
specialists.
So at what point would I switch over from something like Void or Gentoo
to something like Debian or RedHat or Ubuntu or SuSE? I'd say when I
get up to between 3 to 5 admins, and it starts getting too hard to
recruit more from the local community college and train them in Void.
Minimal systems are wonderful for small businesses with tech chops.
They're lousy for those making a living administering or repairing
computer systems. As a business who uses the software gets bigger, the
attraction of minimal systems starts getting less.
Notwithstanding what was said in my preceding paragraph, I think a lot
of businesses' acceptance of the new complexity was as much due to
their lack of knowledge of the alternatives as it was to actual
improvements the complexity brings to their businesses.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Steve Litt]

On Sun, 9 Aug 2015 17:17:54 -0400

Post by Bryan J Smith
I'd just run BSD instead of GNU/Linux.

If OpenBSD offered a robust, working, hardware-assisted Qemu, I'd have
switched to OpenBSD three or four years ago. If their Qemu
implementation was decent, or even if they committed to making it
decent, it would be by far the best OS I've ever used. Matter of fact,
I think I'll install OpenBSD on real metal and see if it now does
hardware assisted VM. I just have to find the right real metal.

I've had bad luck with FreeBSD's package manager, and I'll leave it at
that.

In a distro shootout in late 2014, I came to the conclusion that PC-BSD
was perfectly capable of servicing all of Troubleshooters.Com's needs.
However, the same forces complicating GNU/Linux are at work in the
PC-BSD world.

Post by Bryan J Smith
This "minimalist" farce is really maximum, unsupportable spaghetti,
and results in constantly breaking systems.

What I've observed is that a minimalist system, when used in a
minimalist way, yields a small, modular system quite the opposite of
spaghetti.

When a minimalist system is used for huge systems, there can be
problems. I'll speak of that later.

Post by Bryan J Smith
Why?
Because the "minimalists" don't understand what all is involved, and
miss a lot of things.

They'd notice those things if their use case required them. And since
their use case doesn't require them, they don't need them.

Post by Bryan J Smith
Which is why they shouldn't be on GNU/Linux.

That's an observation based on recent recent changes to some Linux
distros. In 2013, a person wanting only what he needed, with a
not-too-complex use case, was quite satisfied with Debian, as long as
he didn't use Gnome3 or KDE. The person didn't change, his requirements
didn't change, his use case didn't change: Debian changed. So he
migrated to something like what Debian was in 2013. There are still
plenty of them around, in both Linux and BSD incarnations.

I've seen minimalist systems that get glommed with so much cruft, to
add features, that they become spaghetti. I was a maintenance
programmer on one such system back in the mid 1980's. Started clean,
acquired too much new stuff added too quick, needed a rewrite.

Kmail is certainly an example of a simple system that got weighted down
by all sorts of geegaws and ended up a spaghetti project. I have no
idea what Kmail is like today, because I bailed the second they brought
out the doesn't-work Kmail2. But if they rewrote it (and a lot of KDE),
for all I know it's good today.

Twitter was a semi-simple system quickly assembled in Rails, that began
to need both more features and more scaleability. So they did what
every minimalist should when their use case outgrows minimalism:
They're rewriting huge hunks of Twitter in Scala.

Minimalist technology is superior for simple systems. If one's lucky
enough that his simple system becomes usefully featureful and widely
used, a rewrite is in order. The smart minimalist puts away time and
money toward the rewrite, just like the smart homeowner banks money for
his next roof replacement.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

... hardware-assisted Qemu ... hardware assisted VM ...
... a minimalist system, when used in a minimalist way,
yields a small, modular system quite the opposite of spaghetti.

You made two (2) _mutually_exclusive_ statements.

You want VMs ... but you want a minimal system. There's no way you
can have both.

You either adopt modern, dynamic, deterministic services like systemd,
firewalld, nm and other things that modify and work with libvirt in
real-time,

Or ...

You write a lot of incomprehensible spaghetti code that does the same,
but doesn't work, and is definitely _unsupportable_.

Speaking from working with both Red Hat (2012-2014) and HP (2014-2015)
on libvirt and, even more so, OpenStack, in a very "leading" capacity
-- first as 1 of 3 people handling "enablement" of OpenStack at Red
Hat Enablement, and then as the prime, leading Professional Services
guy for HP OpenStack Professional Services -- I can tell you ...

You either learn the new tools ... you create a lot of spaghetti.
It's your choice. ;)

When a minimalist system is used for huge systems, there can be
problems. I'll speak of that later.

And I have a continued problem with shell scripts for just basic libvirt.

I.e., there's a reason why systemd, firewalld, nm, etc... facilities
were created by Red Hat.

Now I could understand "your position" if you didn't use QEMU/KVM.
But since you do ... please join the 21st century. ;)

I.e., It's not me saying "my way dammit.' It's me saying, "If you're
on the same highway as me ... please get out of your '59 before you
cause a huge accident."

They'd notice those things if their use case required them. And since
their use case doesn't require them, they don't need them.

Dude ... one subsystem ... libvirt. DONE.

That's an observation based on recent recent changes to some Linux
distros. In 2013, a person wanting only what he needed, with a
not-too-complex use case, was quite satisfied with Debian, as long as
he didn't use Gnome3 or KDE. The person didn't change, his requirements
didn't change, his use case didn't change: Debian changed. So he
migrated to something like what Debian was in 2013. There are still
plenty of them around, in both Linux and BSD incarnations.

Because Debian's massive installed userbases said ... "If you're going
to change from SysV init, we want systemd instead of Upstart."

Why? Because Debian's massive installed userbases are running a
crapload of libvirt, and they are tired of the non-sense.

Having to deal with hLinux (HP Linux), based on Debian, I too was
sick'n tired of _lacking_ the _basic_ facilities that Fedora-based
solutions had thanx to systemd, firewalld and nm.

Because trying to statically shell script and even have real-time,
"wake-up" forks of shell scripts, is kinda like trying to use an
abacus as a control system for the Space Shuttle. ;)

Anyone who has had to deal with virtualization -- just even on a
single system -- to change network, firewall and other things as VMs
are running can tell you this. Because shell scripts are a PITA that
should _die_, and should have yesterday.

If Upstart would have been "good enough" to solve this, Fedora and Red
Hat would have just _stuck_ with Upstart. Fedora used it from release
9 until 14. RHEL 6, based on Fedora 12-13, shipped with Upstart. But
Upstart did _not_ address it.

So we have the new, _modular_ *d services and *ctl programs.

If you don't like that ... stick with a solution that can run with
static shell scripts and doesn't include virtualization, containers or
other, modular, dynamic solutions that require _real-time_
interaction.

If you did, I would have _0_ issue with your stance. ;)

But because you went down the QEMU route and virtualization ... you're
part of the problem. You're part of the 98% of screaming masses on
the Internet who I do _not_ want to be talking, and filling up Google
searches with utter BS that is so thick, I think I was in Iowa early
into the primaries. ;)

Because you're head-first, "we know better" than people who have

I've seen minimalist systems that get glommed with so much cruft, to
add features, that they become spaghetti. I was a maintenance
programmer on one such system back in the mid 1980's. Started clean,
acquired too much new stuff added too quick, needed a rewrite.

Which is where libvirt was with shell scripts.

Kmail is certainly an example of a simple system that got weighted down
by all sorts of geegaws and ended up a spaghetti project. I have no
idea what Kmail is like today, because I bailed the second they brought
out the doesn't-work Kmail2. But if they rewrote it (and a lot of KDE),
for all I know it's good today.
Twitter was a semi-simple system quickly assembled in Rails, that began
to need both more features and more scaleability. So they did what
They're rewriting huge hunks of Twitter in Scala.
Minimalist technology is superior for simple systems. If one's lucky
enough that his simple system becomes usefully featureful and widely
used, a rewrite is in order. The smart minimalist puts away time and
money toward the rewrite, just like the smart homeowner banks money for
his next roof replacement.

Traditional virtualization is not simple.
And cloud is even less so.

-- bjs

[Kevin Korb]

lol, Brian, we just managed to coax Steve into the concept of trying
out a new OS/distro in a qemu window instead of setting up a temp box.
I know I am bad about that myself but that is because I have a
crapload of spare boxes I can use for testing. He is nowhere near
containers. That isn't really a failing of his it is just a factor of
him running a simple home business.

OTOH, he is also allergic to the concept of a layer of abstraction.
That is the root of everything between why he won't use lvm2 to why he
thinks 'echo select ..... | mysql | awk ...' is better than using the
appropriate library interface from whichever programming language we
are talking about at the time.

Post by Bryan J Smith

... hardware-assisted Qemu ... hardware assisted VM ... ... a
minimalist system, when used in a minimalist way, yields a small,
modular system quite the opposite of spaghetti.

You made two (2) _mutually_exclusive_ statements.
You want VMs ... but you want a minimal system. There's no way
you can have both.
You either adopt modern, dynamic, deterministic services like
systemd, firewalld, nm and other things that modify and work with
libvirt in real-time,
Or ...
You write a lot of incomprehensible spaghetti code that does the
same, but doesn't work, and is definitely _unsupportable_.
Speaking from working with both Red Hat (2012-2014) and HP
(2014-2015) on libvirt and, even more so, OpenStack, in a very
"leading" capacity -- first as 1 of 3 people handling "enablement"
of OpenStack at Red Hat Enablement, and then as the prime, leading
Professional Services guy for HP OpenStack Professional Services --
I can tell you ...
You either learn the new tools ... you create a lot of spaghetti.
It's your choice. ;)

When a minimalist system is used for huge systems, there can be
problems. I'll speak of that later.

And I have a continued problem with shell scripts for just basic libvirt.
I.e., there's a reason why systemd, firewalld, nm, etc...
facilities were created by Red Hat.
Now I could understand "your position" if you didn't use QEMU/KVM.
But since you do ... please join the 21st century. ;)
I.e., It's not me saying "my way dammit.' It's me saying, "If
you're on the same highway as me ... please get out of your '59
before you cause a huge accident."

They'd notice those things if their use case required them. And
since their use case doesn't require them, they don't need them.

Dude ... one subsystem ... libvirt. DONE.

That's an observation based on recent recent changes to some
Linux distros. In 2013, a person wanting only what he needed,
with a not-too-complex use case, was quite satisfied with Debian,
as long as he didn't use Gnome3 or KDE. The person didn't change,
Debian changed. So he migrated to something like what Debian was
in 2013. There are still plenty of them around, in both Linux and
BSD incarnations.

Because Debian's massive installed userbases said ... "If you're
going to change from SysV init, we want systemd instead of
Upstart."
Why? Because Debian's massive installed userbases are running a
crapload of libvirt, and they are tired of the non-sense.
Having to deal with hLinux (HP Linux), based on Debian, I too was
sick'n tired of _lacking_ the _basic_ facilities that Fedora-based
solutions had thanx to systemd, firewalld and nm.
Because trying to statically shell script and even have real-time,
"wake-up" forks of shell scripts, is kinda like trying to use an
abacus as a control system for the Space Shuttle. ;)
Anyone who has had to deal with virtualization -- just even on a
single system -- to change network, firewall and other things as
VMs are running can tell you this. Because shell scripts are a
PITA that should _die_, and should have yesterday.
If Upstart would have been "good enough" to solve this, Fedora and
Red Hat would have just _stuck_ with Upstart. Fedora used it from
release 9 until 14. RHEL 6, based on Fedora 12-13, shipped with
Upstart. But Upstart did _not_ address it.
So we have the new, _modular_ *d services and *ctl programs.
If you don't like that ... stick with a solution that can run with
static shell scripts and doesn't include virtualization, containers
or other, modular, dynamic solutions that require _real-time_
interaction.
If you did, I would have _0_ issue with your stance. ;)
But because you went down the QEMU route and virtualization ...
you're part of the problem. You're part of the 98% of screaming
masses on the Internet who I do _not_ want to be talking, and
filling up Google searches with utter BS that is so thick, I think
I was in Iowa early into the primaries. ;)
Because you're head-first, "we know better" than people who have

I've seen minimalist systems that get glommed with so much cruft,
to add features, that they become spaghetti. I was a maintenance
programmer on one such system back in the mid 1980's. Started
clean, acquired too much new stuff added too quick, needed a
rewrite.

Which is where libvirt was with shell scripts.

Kmail is certainly an example of a simple system that got
weighted down by all sorts of geegaws and ended up a spaghetti
project. I have no idea what Kmail is like today, because I
bailed the second they brought out the doesn't-work Kmail2. But
if they rewrote it (and a lot of KDE), for all I know it's good
today. Twitter was a semi-simple system quickly assembled in
Rails, that began to need both more features and more
scaleability. So they did what every minimalist should when their
use case outgrows minimalism: They're rewriting huge hunks of
Twitter in Scala. Minimalist technology is superior for simple
systems. If one's lucky enough that his simple system becomes
usefully featureful and widely used, a rewrite is in order. The
smart minimalist puts away time and money toward the rewrite,
just like the smart homeowner banks money for his next roof
replacement.

Traditional virtualization is not simple. And cloud is even less
so.
-- bjs
_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Bryan J Smith]

Post by Kevin Korb
lol, Brian,

I know, I'm in my 40s now, and I can still be a "jerk" at times. It's
much easier to talk through these things in-person. In e-mail, it
still comes out at times, especially when I don't use humour, and my
"soap box" sports some borderline ego (even if not intentional).

Post by Kevin Korb
we just managed to coax Steve into the concept of trying
out a new OS/distro in a qemu window instead of setting up a temp box.
I know I am bad about that myself but that is because I have a
crapload of spare boxes I can use for testing. He is nowhere near
containers. That isn't really a failing of his it is just a factor of
him running a simple home business.

I know, but libvirt -- even on a single box -- for QEMU/KVM, really
pushes us beyond using shell scripts.

If people aren't doing libvrt, and aren't managing VMs, not changing
things on-the-fly, I totally understand the "allergies" to the *d/*ctl
changes.

I mean, even I liked Upstart. A lot of us Fedora/RHEL wielding
wennies did. Even people in Red Hat bellyached over the *d/*ctl
changes.

I mean, in writing some of the RHEL7 enablement documentation, I got
deep into firewalld, nmcli et al. ... and in the end, I had to send a
very nice "thank you" to the developers and maintainers. I mean, it's
amazing how much flak gets thrown at time, even in side of Red Hat at
times.

I now understand where things are heading. Not only that, 9 months in
HP, doing lots of Debian and Ubuntu, made me re-appreciate what Red
Hat has developed. It also made me fully understand the Debian
decision better too.

Post by Kevin Korb
OTOH, he is also allergic to the concept of a layer of abstraction.
That is the root of everything between why he won't use lvm2 to why he
thinks 'echo select ..... | mysql | awk ...' is better than using the
appropriate library interface from whichever programming language we
are talking about at the time.

I've long given up telling people what to do ... for themselves.

Take file system mount points ... I don't have a problem with them.
Now I wouldn't do them myself, but to each his own.

Kinda like Cosell on Ali ... "if the man wants to be called Ali, I'll
call him Ali" (paraphrased).

But when you complain about BSD not doing QEMU, libvirt, et al., but
then talk about "minimalist," it's kinda just funny.

I should have made more jokes ... than being a hard-@$$ about it. But
it does go directly to my world, and what I've spent 75% of my time
doing the last 2-3 years. ;)

Control by shell scripts need to _die_. You can still have shell
scripts, but they need to be calling the new facilities that are
resident, real-time and aware of the status of things.

Especially for things like libvirt.

-- bjs

[Bryan J Smith]

DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith - Technology Mercenary

Post by Bryan J Smith
Take file system mount points ... I don't have a problem with them.
Now I wouldn't do them myself, but to each his own.
Kinda like Cosell on Ali ... "if the man wants to be called Ali, I'll
call him Ali" (paraphrased).

Every brilliant and methodical engineer has his/her eccentricities. They
more they work on their own, the more they tend to not converge with others.

While that might have annoyed me in my 20s, by my 30s I started to realize
differing was really me saying "my way dammit!" So I really tried to stop
doing that, because at times I was doing uncommon things myself.

Being the only person who differs in a room doesn't mean you're not
correct. So I always try to keep that in mind, because I've been on that
"other side."

That all said ...

Post by Bryan J Smith
But when you complain about BSD not doing QEMU, libvirt, et al., but
then talk about "minimalist," it's kinda just funny.
it does go directly to my world, and what I've spent 75% of my time
doing the last 2-3 years. ;)

If Steve wasn't both brilliant and methodical, I wouldn't have cared to
respond to him starting those many years ago.

I try to be encouraging with OpenRC and other efforts. After all, systemd
_needs_ to "kept honest."

Even while a German Tiger tank was superior to an American Sherman, there
was more to the debate of a Tiger v. Sherman in battle. Reliability, cost,
"yield" and other things factor in.

To be less overt about it ... just like the Tiger's designers, LP and Kay
don't always see everything that factors in.

-- bjs

[Barry Fishman]

Post by Kevin Korb
lol, Brian, we just managed to coax Steve into the concept of trying
out a new OS/distro in a qemu window instead of setting up a temp box.
I know I am bad about that myself but that is because I have a
crapload of spare boxes I can use for testing. He is nowhere near
containers. That isn't really a failing of his it is just a factor of
him running a simple home business.
OTOH, he is also allergic to the concept of a layer of abstraction.
That is the root of everything between why he won't use lvm2 to why he
thinks 'echo select ..... | mysql | awk ...' is better than using the
appropriate library interface from whichever programming language we
are talking about at the time.

<rant>
I think Steve ultimately just want's control over his own computers.
Why is that asking for too much?

Layering abstractions are useful in system design, but at some point you
find your layers are becoming overly interdependent. We are ending up
with systems far more complex than their functionality requires. Much
better solutions have been around for 40 years but we rather just
continue layer software on weak foundations and patch around the issues.
Systemd is just a mechanism to help a bad design work better. C++ does
not become a better C by layering on a language that is fundamentally
insecure.

I think the biggest issue with Linux is that is run by a trade
association and not one organized for the public interest. Companies
like the idea of an internet organized around big money making servers
and dumb user environments, and most the Linux effort seems to be
building (badly) in that direction. We had mainframes and terminal,
then servers and x-terminals, now the cloud and web browsers. The idea
of distributed environment for which the internet was originally
designed seems to be fading away, and fixing the new security issues of
its components are not being even considered.

Java's primary goal (like Javascript) was to permit remote execution of
code in a secure environment. They have failed so far in that goal.
Java's now controlled by Oracle which seems either incompetent or
un-interested in meeting that design goal. The web consortium is
building a HTML environment so complex that it is unlikely to ever be
secure.

People like to talk about the trade-off between security and usability.
I think there is a bigger trade-off between security and complexity.

It may be an old talk but I think Allen Kay's "Normal Considered
Harmful" presentation still true:

(/rant>
--
Barry Fishman

[Bryan J Smith]

Post by Barry Fishman
<rant>
I think Steve ultimately just want's control over his own computers.
Why is that asking for too much?

And that's the problem.

People have forgotten all the new subsystems in the kernel, all the
new, required "process awareness" between services, all of the
"message passing" things use to communicate, that have been developed
over the last 20+ years.

Heck, remember all of the anti-Red Hat commentary when they made SysV
init scripts the default? "We don't need SysV init, rc scripts work
fine!" ;)

And now, 20 years later ... it's the same thing, all over again.
System management was falling "way, way behind" in using _existing_
systems. All 100% standardized, open source facilities -- things that
were developed _not_ by systemd, or Upstart for that matter, but
because they were _needed_.

So we now have the *d/*ctl "generation." You cannot do virtualization
today without it. I'm not even talking containers yet, which brings
its own set of new baggage. All sorts of services require it, it's
not optional. And anyone who thinks it's only for desktops is grossly
mistaken.

I.e., the large Debian userbases who wanted it have the same "itches"
that Red Hat userbases who asked for it, and someone finally
"scratched" it.

I speak 100% "from the field," even for "standalone servers." ;)

Post by Barry Fishman
Layering abstractions are useful in system design,
but at some point you find your layers are becoming
overly interdependent.

This "inter-dependent" argument is muchg like the "monolithic"
argument ... it's based on assumption, almost always from
unfamiliarity. Because you know what is "inter-dependent"?

The Internet!

You have DNS and RARP (DHCP) and other services that _must_ work.
Same concept inside of a system -- a system manager that tracks
processes and available resources, message passing so services so
firewall rules can be updated, network interfaces brought up and down
for VMs, etc...

If you don't want that, then ... honestly ... go back to BSD.

Because as even Steve pointed out -- and I jumped on -- libvirt and
virtualization management has _pushed_ this upon everyone. OSes and
platforms that don't do it well, like BSD, are the ones "behind."

And that's fine ... _if_ you're _not_ doing virtualization. ;)

But if you want things to "just work" ... sorry, you cannot have a
firewall, network manager and other things that are ignorant of
changes in the infrastructure. Because _that's_ what virtualization
is ...

Virtual infrastructure. ;)

Post by Barry Fishman
We are ending up with systems far more complex than
their functionality requires.

For a single-user system? Of course, you're 100% correct. But for an
automated, multi-VM system ... even for a single user? Hardly!

And that's the thing ...

The new solutions actually make things _easier_! But if one doesn't
stop to learn them, then they seem "complex."

Anyone who uses "systemctl status" for a month will quickly say ...
"My God, I do _not_ want to go back to old SysV init!

Post by Barry Fishman
Much better solutions have been around for 40 years but we
rather just continue layer software on weak foundations and
patch around the issues.

Er, um, isn't that spaghetti shell scripting?

Post by Barry Fishman
Systemd is just a mechanism to help a bad design work better.

Please explain this?

So what you're saying is ... the init subsystem should be _ignorant_
of not only process status "in real time," but more importantly,
should _not_ care if a resource goes down or is unavailable? It also
shouldn't audit and track logs? That it also shouldn't corral
services and provide a deterministic way to kill everything related to
a service? Etc..., etc..., etc...?

Because systemd actuall _solves_ a lot of things. But, for starters,
this includes the long-standing "zombie nation" of forking services.
That alone interested me from Day 1, even if I do _not_ agree with
everything systemd does ...

Or every *d/*ctl for that matter.

But if you disagree with all of that, regardless ... then create
something better! That's open source for you! ;)

But even outside open source ... things like Sun's SMF _also_ exist.
I.e., this isn't a Linux-only thing. Most UNIX flavors have
implemented similar.

So ... again ... if you don't like that, BSD is most excellent!

But as even Steve pointed out ... he cannot get Linux-like
virtualization with BSD.

Catch-22, eh? ;)

Post by Barry Fishman
C++ does not become a better C by layering on a language that
is fundamentally insecure.

"Insecure"?
Or not "strongly typed?"

And ... even with that said, that's why there _are_ other languages. ;)
But there's a reason why Boost exists for C++ too.

As always ... if you don't agree, create something better!
That's community at its finest.

But here's the thing ... once you start getting into it, then you see
_why_ and _how_ something like the *d/*ctl solutions came about.
Because it's the first solution that isn't legacy designed to ignorant
of all these pre-existing, open, standards-based interfaces in the
kernel, subsystems of Linux, D-Bus message passing between programs,
etc...

And then things start to make sense.

If you don't want such ... then BSD is available, with all its
limitations, but also its simplifications. But if BSD does everything
you need, why not use BSD? Seriously, it's a great OS and platform.

Post by Barry Fishman
I think the biggest issue with Linux is that is run by a trade
association and not one organized for the public interest. Companies
like the idea of an internet organized around big money making servers
and dumb user environments, and most the Linux effort seems to be
building (badly) in that direction.

Oh boy. I don't know how to answer this.

Because from what I see ... companies have requirements, and Linux
institutions -- non-profit as much as for-profit, with a lot of
for-profit companies paying the salaries of developers who are _not_
tied to that profit at all -- solving those needs.

But most Linux users don't see that.

They don't understand why we need threaded C libraries or long-term
ABI or other things, and they definitely don't realize the people who
pay money are the ones who pay developer salaries, so they get what
they want. And that's what's happened.

Post by Barry Fishman
We had mainframes and terminal,
then servers and x-terminals, now the cloud and web browsers. The idea
of distributed environment for which the internet was originally
designed seems to be fading away, and fixing the new security issues of
its components are not being even considered.

You mean like any systemd "module" someone contributes much like any
Apache "module" someone contributes?

This argument is getting old.

I.e., you can find all sorts of "security" issues with any systemd
contribution just like any Apache contribution. But the same people
who make that argument _refuse_ to recognize that systemd doesn't ship
with those modules, much like Apache doesn't either -- because they
are _not_ flushed out contribs, and often dropped for a reason.

That said ...

systemd actually _improves_ security over legacy SysV init. The
isolation into cgroups, the leveraging of contexts (if SELinux is
enabled), etc... This goes even further with libvirt and even more so
with containers too. But people will assume otherwise, throw the
"monolithic" tag on systemd, which isn't remotely applicable to
systemd any more than Apache is not "monolithic," etc...

All the meanwhile people stick their fingers in their ears and go ...
"I cannot hear you" anytime someone gets into the _technical_ meat.

Post by Barry Fishman
Java's primary goal (like Javascript) was to permit remote execution of
code in a secure environment. They have failed so far in that goal.
Java's now controlled by Oracle which seems either incompetent or
un-interested in meeting that design goal. The web consortium is
building a HTML environment so complex that it is unlikely to ever be
secure.

I'd argue that Google is more "incompetent" than Oracle when it comes
to Java, but that's another debate.

In any case ... these are _not_ even related to what the *d/*ctl
solutions are solving.

Post by Barry Fishman
People like to talk about the trade-off between security and usability.
I think there is a bigger trade-off between security and complexity.

While that's true ... you know what is worse for security?

Spaghetti code of shell scripts. ;)

Try playing with VMs for awhile and attempt to change network,
firewall and other things, especially if you have to restart libvirt.
Now tell me how that is "less complex" and "more secure" using shell
scripts?

I can take you on a tour of some examples in-person if you like. ;)

Post by Barry Fishman
It may be an old talk but I think Allen Kay's "Normal Considered
http://youtu.be/FvmTSpJU-Xc

BSD is a great OS. I highly recommend it.

Of course, you cannot do things on it like you can with GNU/Linux,
which is the quandry Steve is dealing with.

And yet ... all the meanwhile, the solutions are there.

E.g., learn rd.break for boot-time recovery. Learn elementary
systemctl to tame your entire system. Etc...

It's not hard. People are learning it. And guess what? It actually
... gasp ... makes sense and _reduces_ already _existing_ complexity.
;)

I mean ...
- systemd didn't create inter-dependent services
- systemd didn't create udev and services dependent on resources
- systemd didn't create the need for message pagging
- journald didn't cause syslog to be unable to capture some kernel messages
- firewalld didn't cause shell scripts to be unable to change on network changes
- nm didn't cause network changes to happen
- libvirt didn't create any new virtualization concepts
- etc...

There are people who understand this. And they are deploying
GNU/Linux in areas where other platforms are doing similar, but are
not very standardized, much less open source.

And then there are people who are still stuck with an '80s mindset of
UNIX. They really should be running BSD instead of GNU/Linux. And
they need to understand what they lose.

Like Steve even recognizes, even if he fully doesn't understand why yet. ;)

-- bjs

[Steve Litt]

On Mon, 10 Aug 2015 10:35:44 -0400

Post by Bryan J Smith
So we now have the *d/*ctl "generation." You cannot do virtualization
today without it. I'm not even talking containers yet, which brings
its own set of new baggage. All sorts of services require it, it's
not optional. And anyone who thinks it's only for desktops is grossly
mistaken.

And that's fine. Make it a unit you can add on, without disrupting
major portions of your OS. Those who need the add on unit can use it,
those who don't won't. The *only* reason so many hate systemd is because
it was forced on them.

I'm still puzzled as to why so many people get so indignant that I
threw KDE and systemd off my own computer. It's not like I walked into
their workplace and took away *their* KDE and systemd.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Bryan J Smith]

Post by Steve Litt
And that's fine. Make it a unit you can add on, without disrupting
major portions of your OS. Those who need the add on unit can use it,
those who don't won't.

I'm utterly not following.

Post by Steve Litt
The *only* reason so many hate systemd is because it was forced
on them.

Huh?

Post by Steve Litt
I'm still puzzled as to why so many people get so indignant that I
threw KDE and systemd off my own computer. It's not like I walked into
their workplace and took away *their* KDE and systemd.

I run Fedora. I _never_ have KDE installed ... at all. I also do
_not_ install GNOME ... at all either. LXDE alone. But one can also
have KDE installed ... alone too. I'm not following your logic.

But system management isn't an "add-on." It's a solution that manages
things. If you have libvirt, which is required for QEMU/KVM today,
then you have to have something that can dynamically update it.

If you have a solution for that ... I'm _all_ears_. But right now, no
one does ... sans the *d/*ctl solutions. Hence why they weren't
"forced" upon anyone ... but "requested."

The Debian vote was a perfect example of this. ;)
There are those who love to argue, from lack of experience.
And there are those who have to have something that works.

It was very interesting debate and corresponding vote to watch.

-- bjs

[Steve Litt]

On Mon, 10 Aug 2015 21:42:09 -0400

Post by Bryan J Smith
I run Fedora. I _never_ have KDE installed ... at all. I also do
_not_ install GNOME ... at all either. LXDE alone. But one can also
have KDE installed ... alone too. I'm not following your logic.

This is easy to explain.

Imagine you live in a world where, when *you* choose not to have KDE
installed, because *you* don't like KDE for some reason, people on a
plethora of LUG mailing lists, and of course on Debian Users, call you:

* Disempowering
* Against progress
* A neckbeard
* Out of touch
* You don't know the whole story
* You're living in the 20th century

You try to explain to them that nothing in your computer usage requires
or can benefit from KDE enough to justify its immensity, and they go
right on with the same set of responses. They act personally offended
that you're not installing KDE.

This is what everyday life is like for the person who chooses to forego
systemd, and actually admits it online. We're not talking one critic.
We're not talking five critics. We're talking maybe thirty to fifty
prolific critics on ten different LUG mailing lists, and of course
another twenty on the mailing list of each distro that's chosen systemd.

You once discussed the phenominon of every last bug being summarily
blamed on systemd. I've seen that happen quite a bit, and it must be
frustrating as hell. "Hey, my cut command doesn't work on Jessie, that
damn systemd broke it!"

Now imagine that you're a technologically proficient computer *user*
who just uses his computer to run his business, and you've been using
Linux to run it for a decade. Any virtualization you do is quite well
handled by qemu. Because keystrokes are faster than a mouse, and
because you believe screen real estate is valuable, you use Openbox.
You boot once a week, so you don't care whether the boot takes a second
or a minute. You've never in your life seen any boot indeterminancies
that could be caused by the kernel's starting things in parallel, in
indeterminate order. You would derive no major benefit from systemd. You
want a nice, simple Linux like Debian, so that's what you use. And then
Debian goes systemd, so you switch to Void Linux or Manjaro-OpenRC or
Funtoo or Devuan.

And all of a sudden, you're a disempowering anti-innovation neckbeard
stuck in the 20th century who's out of touch and doesn't know the whole
story. And you're being told that by fifty different people. This is
everyday life for the guy who chooses not to use systemd.

I don't get it. I use Vim, Barry uses Emacs, we would never switch
places, but we don't call each other names: We recognize that the other
is productive in the environment of his choice. I use Python, Kevin uses
Perl, we would never switch places, but we don't call each other
names: We recognize that the other is productive in the environment of
his choice. I use Openbox, Joe uses Unity, we would never switch
places, but we don't call each other names: We recognize that the other
is productive in the environment of his choice.

And then there's this one exception called systemd, where every single
bug is caused by systemd, and everyone not using systemd is an out of
touch neckbeard. I don't get it.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Shawn McMahon]

Imagine an argument where you construct an object out of dried grasses,
shaped roughly like a human. Then you present reasons why this grassy
hominid is bad, and how comparing you to him is therefore an act of
aggression.

There should be a term for that.

Post by Steve Litt
On Mon, 10 Aug 2015 21:42:09 -0400

Post by Bryan J Smith
I run Fedora. I _never_ have KDE installed ... at all. I also do
_not_ install GNOME ... at all either. LXDE alone. But one can also
have KDE installed ... alone too. I'm not following your logic.

This is easy to explain.
Imagine you live in a world where, when *you* choose not to have KDE
installed, because *you* don't like KDE for some reason, people on a
* Disempowering
* Against progress
* A neckbeard
* Out of touch
* You don't know the whole story
* You're living in the 20th century
You try to explain to them that nothing in your computer usage requires
or can benefit from KDE enough to justify its immensity, and they go
right on with the same set of responses. They act personally offended
that you're not installing KDE.
This is what everyday life is like for the person who chooses to forego
systemd, and actually admits it online. We're not talking one critic.
We're not talking five critics. We're talking maybe thirty to fifty
prolific critics on ten different LUG mailing lists, and of course
another twenty on the mailing list of each distro that's chosen systemd.
You once discussed the phenominon of every last bug being summarily
blamed on systemd. I've seen that happen quite a bit, and it must be
frustrating as hell. "Hey, my cut command doesn't work on Jessie, that
damn systemd broke it!"
Now imagine that you're a technologically proficient computer *user*
who just uses his computer to run his business, and you've been using
Linux to run it for a decade. Any virtualization you do is quite well
handled by qemu. Because keystrokes are faster than a mouse, and
because you believe screen real estate is valuable, you use Openbox.
You boot once a week, so you don't care whether the boot takes a second
or a minute. You've never in your life seen any boot indeterminancies
that could be caused by the kernel's starting things in parallel, in
indeterminate order. You would derive no major benefit from systemd. You
want a nice, simple Linux like Debian, so that's what you use. And then
Debian goes systemd, so you switch to Void Linux or Manjaro-OpenRC or
Funtoo or Devuan.
And all of a sudden, you're a disempowering anti-innovation neckbeard
stuck in the 20th century who's out of touch and doesn't know the whole
story. And you're being told that by fifty different people. This is
everyday life for the guy who chooses not to use systemd.
I don't get it. I use Vim, Barry uses Emacs, we would never switch
places, but we don't call each other names: We recognize that the other
is productive in the environment of his choice. I use Python, Kevin uses
Perl, we would never switch places, but we don't call each other
names: We recognize that the other is productive in the environment of
his choice. I use Openbox, Joe uses Unity, we would never switch
places, but we don't call each other names: We recognize that the other
is productive in the environment of his choice.
And then there's this one exception called systemd, where every single
bug is caused by systemd, and everyone not using systemd is an out of
touch neckbeard. I don't get it.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Steve Litt]

I don't get it.

On Tue, 11 Aug 2015 13:25:47 -0400

Post by Shawn McMahon
Imagine an argument where you construct an object out of dried
grasses, shaped roughly like a human. Then you present reasons why
this grassy hominid is bad, and how comparing you to him is therefore
an act of aggression.
There should be a term for that.
On Tue, Aug 11, 2015 at 1:09 PM, Steve Litt

Post by Steve Litt
On Mon, 10 Aug 2015 21:42:09 -0400

Post by Bryan J Smith
I run Fedora. I _never_ have KDE installed ... at all. I also do
_not_ install GNOME ... at all either. LXDE alone. But one can
also have KDE installed ... alone too. I'm not following your
logic.

This is easy to explain.
Imagine you live in a world where, when *you* choose not to have KDE
installed, because *you* don't like KDE for some reason, people on a
* Disempowering
* Against progress
* A neckbeard
* Out of touch
* You don't know the whole story
* You're living in the 20th century
You try to explain to them that nothing in your computer usage
requires or can benefit from KDE enough to justify its immensity,
and they go right on with the same set of responses. They act
personally offended that you're not installing KDE.
This is what everyday life is like for the person who chooses to
forego systemd, and actually admits it online. We're not talking
one critic. We're not talking five critics. We're talking maybe
thirty to fifty prolific critics on ten different LUG mailing
lists, and of course another twenty on the mailing list of each
distro that's chosen systemd.
You once discussed the phenominon of every last bug being summarily
blamed on systemd. I've seen that happen quite a bit, and it must be
frustrating as hell. "Hey, my cut command doesn't work on Jessie,
that damn systemd broke it!"
Now imagine that you're a technologically proficient computer *user*
who just uses his computer to run his business, and you've been
using Linux to run it for a decade. Any virtualization you do is
quite well handled by qemu. Because keystrokes are faster than a
mouse, and because you believe screen real estate is valuable, you
use Openbox. You boot once a week, so you don't care whether the
boot takes a second or a minute. You've never in your life seen any
boot indeterminancies that could be caused by the kernel's starting
things in parallel, in indeterminate order. You would derive no
major benefit from systemd. You want a nice, simple Linux like
Debian, so that's what you use. And then Debian goes systemd, so
you switch to Void Linux or Manjaro-OpenRC or Funtoo or Devuan.
And all of a sudden, you're a disempowering anti-innovation
neckbeard stuck in the 20th century who's out of touch and doesn't
know the whole story. And you're being told that by fifty different
people. This is everyday life for the guy who chooses not to use
systemd.
I don't get it. I use Vim, Barry uses Emacs, we would never switch
places, but we don't call each other names: We recognize that the
other is productive in the environment of his choice. I use Python,
Kevin uses Perl, we would never switch places, but we don't call
each other names: We recognize that the other is productive in the
environment of his choice. I use Openbox, Joe uses Unity, we would
never switch places, but we don't call each other names: We
recognize that the other is productive in the environment of his
choice.
And then there's this one exception called systemd, where every
single bug is caused by systemd, and everyone not using systemd is
an out of touch neckbeard. I don't get it.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Alexandros Nipirakis]

I might be wrong (took a few moments) but I believe that Shawn was
describing a "straw man argument"

Post by Steve Litt
I don't get it.
On Tue, 11 Aug 2015 13:25:47 -0400

Post by Shawn McMahon
Imagine an argument where you construct an object out of dried
grasses, shaped roughly like a human. Then you present reasons why
this grassy hominid is bad, and how comparing you to him is therefore
an act of aggression.
There should be a term for that.
On Tue, Aug 11, 2015 at 1:09 PM, Steve Litt

Post by Steve Litt
On Mon, 10 Aug 2015 21:42:09 -0400

Post by Bryan J Smith
I run Fedora. I _never_ have KDE installed ... at all. I also do
_not_ install GNOME ... at all either. LXDE alone. But one can
also have KDE installed ... alone too. I'm not following your
logic.

This is easy to explain.
Imagine you live in a world where, when *you* choose not to have KDE
installed, because *you* don't like KDE for some reason, people on a
* Disempowering
* Against progress
* A neckbeard
* Out of touch
* You don't know the whole story
* You're living in the 20th century
You try to explain to them that nothing in your computer usage
requires or can benefit from KDE enough to justify its immensity,
and they go right on with the same set of responses. They act
personally offended that you're not installing KDE.
This is what everyday life is like for the person who chooses to
forego systemd, and actually admits it online. We're not talking
one critic. We're not talking five critics. We're talking maybe
thirty to fifty prolific critics on ten different LUG mailing
lists, and of course another twenty on the mailing list of each
distro that's chosen systemd.
You once discussed the phenominon of every last bug being summarily
blamed on systemd. I've seen that happen quite a bit, and it must be
frustrating as hell. "Hey, my cut command doesn't work on Jessie,
that damn systemd broke it!"
Now imagine that you're a technologically proficient computer *user*
who just uses his computer to run his business, and you've been
using Linux to run it for a decade. Any virtualization you do is
quite well handled by qemu. Because keystrokes are faster than a
mouse, and because you believe screen real estate is valuable, you
use Openbox. You boot once a week, so you don't care whether the
boot takes a second or a minute. You've never in your life seen any
boot indeterminancies that could be caused by the kernel's starting
things in parallel, in indeterminate order. You would derive no
major benefit from systemd. You want a nice, simple Linux like
Debian, so that's what you use. And then Debian goes systemd, so
you switch to Void Linux or Manjaro-OpenRC or Funtoo or Devuan.
And all of a sudden, you're a disempowering anti-innovation
neckbeard stuck in the 20th century who's out of touch and doesn't
know the whole story. And you're being told that by fifty different
people. This is everyday life for the guy who chooses not to use
systemd.
I don't get it. I use Vim, Barry uses Emacs, we would never switch
places, but we don't call each other names: We recognize that the
other is productive in the environment of his choice. I use Python,
Kevin uses Perl, we would never switch places, but we don't call
each other names: We recognize that the other is productive in the
environment of his choice. I use Openbox, Joe uses Unity, we would
never switch places, but we don't call each other names: We
recognize that the other is productive in the environment of his
choice.
And then there's this one exception called systemd, where every
single bug is caused by systemd, and everyone not using systemd is
an out of touch neckbeard. I don't get it.
SteveT
Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Bryan J Smith]

Post by Alexandros Nipirakis
I might be wrong (took a few moments) but I believe that Shawn was
describing a "straw man argument"

Well ... I still like to take arguments head-on, regardless.

I kinda kicked it into high gear once Steve brought up QEMU and BSD.
But it's now been [re-]beaten like a very dead horse. I am guilty of
that.

The deep Debian maintainer discussions were the most enlightening for
me, because they provide a non-Arch, Red Hat, SuSE, etc... "objective"
look. Especially since Debian had stayed SysV init, and hadn't
adopted OpenRC, Upstart or systemd.

The only time I _ever_ see boot-time speed brought up is in the
context of Upstart's parallelism, and _only_ early on (years ago) when
people were saying, "Why do we need systemd? We already have
Upstart!"

As most find, including a lot of Debian maintainers ... once you look
deep, you realize it's more than just parallelism/boot-time and
solving only 1 or 2 outstanding issues with SysV init/OpenRC.

True determinism, isolation and security, auditing and troubleshooting, etc...

-- bjs

[Alexandros Nipirakis]

I was just talking about the joke Shawn made (which, after I understood it,
was actually pretty funny - may have to use that one day).

In general, I think the discussion was interesting. I know nearly nothing
about systemd, or why it is (or is not controversial). The discussion
proved to me that I really need to take some time to learn it better since
I do use it on my systems (but never really understood it).

I realize I may be opening up a can of worms here - but from what you guys
are describing it sounds a lot like how windows starts and stops services
(not quite great in older versions, getting better in newer versions). One
can debate whether or not that's a good thing, but it seems to me that
dependent services is pretty important on a relatively new operating system
(and, knowing service a successfully started would obviously be important
before starting service b). Again, no idea how SysV, init, or systemd
differ, but I know in my experience having to live with these things in my
environments.

For what its worth, there is a big difference between running something at
your house for your own purposes and running a database server for
thousands (or millions) of clients. There are things I would do on my home
boxes that I wouldn't do on my work ones because of security and other
considerations.

As I said, I think this was a great discussion, and opportunity for
learning :)

Post by Bryan J Smith

Post by Alexandros Nipirakis
I might be wrong (took a few moments) but I believe that Shawn was
describing a "straw man argument"

Well ... I still like to take arguments head-on, regardless.
I kinda kicked it into high gear once Steve brought up QEMU and BSD.
But it's now been [re-]beaten like a very dead horse. I am guilty of
that.
The deep Debian maintainer discussions were the most enlightening for
me, because they provide a non-Arch, Red Hat, SuSE, etc... "objective"
look. Especially since Debian had stayed SysV init, and hadn't
adopted OpenRC, Upstart or systemd.
The only time I _ever_ see boot-time speed brought up is in the
context of Upstart's parallelism, and _only_ early on (years ago) when
people were saying, "Why do we need systemd? We already have
Upstart!"
As most find, including a lot of Debian maintainers ... once you look
deep, you realize it's more than just parallelism/boot-time and
solving only 1 or 2 outstanding issues with SysV init/OpenRC.
True determinism, isolation and security, auditing and troubleshooting, etc...
-- bjs
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Bryan J Smith]

Post by Alexandros Nipirakis
I was just talking about the joke Shawn made (which, after I understood it,
was actually pretty funny - may have to use that one day).

I'm way too serious for LUG lists way too often. Shawn has always
been great comic relief.

Post by Alexandros Nipirakis
In general, I think the discussion was interesting. I know nearly nothing
about systemd, or why it is (or is not controversial). The discussion
proved to me that I really need to take some time to learn it better since I
do use it on my systems (but never really understood it).
I realize I may be opening up a can of worms here - but from what you guys
are describing it sounds a lot like how windows starts and stops services
(not quite great in older versions, getting better in newer versions).

Oh no, nothing like NT service manager.

At a stretch, it would be more like MacOS X's launcherd.
A little closer would be Solaris' Services Management Facility (SMF).

But the entire *d/*ctl "shift" in the GNU/Linux platform goes beyond.

Post by Alexandros Nipirakis
One can debate whether or not that's a good thing, but it seems
to me that dependent services is pretty important on a relatively
new operating system (and, knowing service a successfully started
would obviously be important before starting service b).

Upstart already provides some of this.
Even some SysV init implementations had a few facilities.

Linux Standards Base (LSB) SysV Init even defines dependencies, which
_both_ Upstart and systemd respect. I.e., if you want "legacy" SysV
init style execution, both Upstart and systemd _implement_ backward
compatibility.

But systemd doesn't just do "services." It's designed around the
general principal of an "unit." So you can track resources and other
dependencies too.

E.g., most Red Hat customers, pre-RHEL7, used to use cman and Cluster
Services -- on a single node (not a Cluster) -- just to track resource
and service dependency. Either that, or grab monit (totally
_unsupported_) from Fedora's Extra Packages for Enterprise Linux
(EPEL).

Upstart was incapable of solving that "larger issue."

Then there are all the other, modular *d services and their respective
*ctl programs. If you do virtualization, you're using libvirt.
Trying to use static network and firewall scripts on live interfaces
that start/stop VMs and other things is a mess.

So those solutions became dynamic as well.

Post by Alexandros Nipirakis
Again, no idea how SysV, init, or systemd differ, but I know in my
experience having to live with these things in my environments.

And before modular SysV init, we had static RC scripts. Red Hat, SuSE
and others were lambasted by many back then for pushing SysV init.
But Linux had a lot less sysadmins and users back then, and they
weren't as rabid.

Now we have modular, dynamic facilities for everything from inside the
kernel itself to userspace services like devices, message passing,
etc..., beyond just basic, process management. SysV init doesn't know
how to handle those. Upstart could only handle a couple of things,
like respawning processes.

The whole *d/*ctl architecture/program model is trying to get ahold of
these things ... even for standalone servers, as much as desktops.
Their needs are often inter-related more than people realize.

E.g., two things that are absolutely untrue are that systemd was
designed for desktops and is monolithic. It was designed for servers,
and is far more modular than SysV init in several ways.

People say the same thing about minimal initrds and static kernels,
but in reality, they are far more monolithic than Dracut and modular
initrds. The idea of "better" is a comment that is often from a point
of view.

But with libvirt today ... scripts don't work. Unless, of course, you
don't mind rebooting any time you make a VM or network change.

Post by Alexandros Nipirakis
For what its worth, there is a big difference between running something
at your house for your own purposes and running a database server for
thousands (or millions) of clients. There are things I would do on my
home boxes that I wouldn't do on my work ones because of security
and other considerations.

And yet ... they are inter-related.

It's funny how the same people say systems is designed for desktops,
not servers, but then also turn around and say they don't need
something designed for enterprise servers.

The overwhelming majority of systemd's solutions are designed for
standalone servers, even if multi-system solutions will eventually use
those facilities on each server.

Post by Alexandros Nipirakis
As I said, I think this was a great discussion, and opportunity for learning
:)

And that's what I always look for.

It's difficult to teach people who want to have meta-arguments,
instead of technical ones. They say systemd goes against UNIX
philosophy.

That's patently false, sans maybe BSD philosophy, which I concede. Of
course, BSD doesn't do a lot of things that not only GNU/Linux does,
but a lot of other UNIX flavors.

In fact, most people compare at least the "services" unit of systemd
to Solaris' early SMF. Although most people, once they learn
systemd, say is ... "Oh, so this is actually what Sun promised SMF
would do, but systemd actually does."

In other words ... what systemd does is hardly unique or what people
have wanted ... or should I re-phrase ... have had _hard_ requirements
for, in the past. ;)

Which goes back to the whole Debian consideration.

It was becoming more and more clear that long-standing issues with
SysV init were continuing to be a major issue. So ... do they go
Upstart? Or do they go systemd? Or not change, or maybe look at
OpenRC?

If you remotely pushed systemd, you were cut to bits by people en
masse. And the Internet is still filled with anti-systemd FUD any
time you want to actually read up on it.

LP's 21-part (currently) blog "systemd for SysAdmins" is the best
intro I can give. It starts back in 2010, when he was still "selling"
systemd over Upstart when it comes to Upstart's long-standing argument
of "parallelism" in Part I, and goes through that latest entries.

So you can see the entire history of systemd's development, and
related *d/*ctl services/programs.

I merely offered the prior, late 2013 Debian list posting [1] as a
great example of what many Debian maintainers came to once the
steering committee asked maintainers to start evaluating different
init replacements for possible adoption.

Because it's been the most "objective" post I've ever seen, including
calling out the 3 major problems that OpenRC doesn't solve, that I
always highlight. The "zombie nation" has always been my #1
complaint.

-- bjs

[2] "Bug#727708: init system other points, and conclusion"
- https://lists.debian.org/debian-ctte/2013/12/msg00234.html

[Shawn McMahon]

Post by Bryan J Smith
E.g., most Red Hat customers, pre-RHEL7, used to use cman and Cluster
Services -- on a single node (not a Cluster) -- just to track resource
and service dependency. Either that, or grab monit (totally
_unsupported_) from Fedora's Extra Packages for Enterprise Linux
(EPEL).

Hell, we're just starting to get away from using VCS Cluster Server One for
it. Of applications that handle their clustering themselves. Can't go into
detail here, NDAs. But damn.

We're also not doing RHEL 7 yet. I've got CentOS 7 on my desktop, but if
you ask our PC support people they'll tell you it's running Windows 7 but
was powered off years ago. Shhhhhhh.

[Steve Litt]

On Tue, 11 Aug 2015 15:18:09 -0600

The
discussion proved to me that I really need to take some time to learn
it better since I do use it on my systems (but never really
understood it).

I find this an excellent starting place:

https://rhsummit.files.wordpress.com/2014/04/summit_demystifying_systemd1.pdf

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

[Bryan J Smith]

Post by Steve Litt

The discussion proved to me that I really need to take some time to learn
it better since I do use it on my systems (but never really
understood it).

https://rhsummit.files.wordpress.com/2014/04/summit_demystifying_systemd1.pdf

LP himself has done systemd at every, recent Red Hat Summit, either
with Kay (another developer on systemd/journald) or with one of Red
Hat's Solution Architects, my friend Ben. [2013] [2014] [2015]

LP also has done a 5+ year, 21-part Blog series called "systemd for
Administrators" which Steve [indirectly re-]introduced us to earlier.
It starts from 2010, when "Why systemd over Upstart?" was the question
-- especially as pro-Upstart people were pimp'ing it's parallelism --
and really goes into all of the issues systemd and the *d/*ctl tools
have been solving up through today. [Blog]

I highly recommend hitting Summit presentations and videos, which Red
Hat is good about putting up over the week after Summit. [Summit]

My personal favorite is what I call "The Shak & Woodman Show" -- a
2-part, 2-hour "Performance Tuning" session is always heavily attended
for good reason -- it's a slice of the deep stuff that Red Hat has in
their highly rated, week-long RH442 course. RH442 was built on the
backs of not only Consulting Engineers and Developers like Shak &
Woodman, but Consultants on Wall Street, in Hollywood, etc... and many
applications are cross-distro and/or apply to most, similar kernel
versions (or newer kernels in the case of backports).

-- bjs

[2013] Summit 2013: "Getting Ready for systemd, the new Red Hat
Enterprise Linux 7 Service Manager"
Slides: https://rhsummit.files.wordpress.com/2013/06/poettering_f_0945_getting_ready_for_systemd-the-new-red-hat-enterprise-linux-7-service-manager.pdf
Video: https://access.redhat.com/videos/403833

[2014] "Summit 2014: Demystifying systemd - A Practical Guide"
Slides: https://rhsummit.files.wordpress.com/2014/04/summit_demystifying_systemd1.pdf
Video: (having trouble locating on Red Hat Access Portal and YouTube
-- might have been yanked in favor of 2015)

[2015] Summit 2015: "Demystifying systemd - 2015 Edition"
Slides: http://videos.cdn.redhat.com/summit2015/presentations/12720_demystifying-systemd.pdf
Video:

[Blog] Blog: The systemd for Administrators Blog Series
Link-Anchor: http://www.freedesktop.org/wiki/Software/systemd/#thesystemdforadministratorsblogseries

[Summit] Red Hat Summit 2015
Presentations/Videos: http://www.redhat.com/summit/2015/presentations/
YouTube Channel: https://www.youtube.com/user/redhatsummit

[Bryan J Smith]

LP et al. and systemd has basically reached infamy on the order of
NASA and W.+CIA.

I.e., anyone who has been through 2-3 years of engineering can easily
see through nearly all arguments on the Moon Landings being faked and
that a CIA cell under W.'s orders took down the WTC.

There are only a few, legitimate questions that remain in each case
where things aren't well explained or are hard-to-believe goofs.
E.g., video issues in Apollo 11 (NASA "shotgunning" the camera) and/or
12 (Al Bean destroying the camera), as well as the destruction of one
of the WTC buildings (which NIST could not).

But over 99% of people have never been through 2-3 years of an
engineering program, and aren't even solid in their basic, 18th
century, classical physics, to remember basic concepts that should
give them a hint. So they will believe all sorts of wild, false
conspiracy theories, to the point they are a total distraction from
the few questions and issues that remain.

In the same regard, we're now seeing the fruits of a renewed anti-LP
campaign to focus on message passing and shared objects. This isn't
new. And systemd didn't introduce any such dependencies ... virtually
every Linux system does today. systemd only chose to not be ignorant,
and actually load libdbus to be able to "read (and understands) the
signs on the road" that are "already being used (and placed) by many
drivers."

But since LP et al., like many others, have offered a "better D-Bus"
solution, the attacks are now on. The correlations to "Microsoft COM
being in my init!" is being thrown by the anti-systemd crowd, despite
others introducing other "better D-Bus" solutions. Even D-Bus itself
has been a sprawling mess, and affects the system _regardless_ of
whether the init (or system manager, in the case of systemd) "can
reads the signs" or not.

Ironically ... this was all predicted by many people in the '90s, and
solutions like CORBA were designed to solve a lot of the issues with
DCE, COM, etc... Kinda interesting we're here, when people said we'd
be here some 15+ years ago, and systemd has _nothing_ to do with it.
Yet it just takes a little argument and a little stretching to blame
LP et al. and systemd for it.

Which is how people can make LP et al. and systemd the "lightning rod"
for it. Because over 99% of users have never heard of D-COP or CORBA
or understand how various services _already_ use D-Bus, and have since
_before_ systemd existed. So they can easily take on arguments that
blame NASA or W. for various events, because they cannot follow basic
concepts.

And we ... as a community ... expose just how ignorant and polarizing
we've become.

-- bjs

[Bryan J Smith]

Post by Steve Litt
This is easy to explain.
Imagine you live in a world where, when *you* choose not to have KDE
installed, because *you* don't like KDE for some reason, people on a
* Disempowering
* Against progress
* A neckbeard
* Out of touch
* You don't know the whole story

^ Putting the first 4 aside ... that 5th one may fit. But moving in ...

Post by Steve Litt
* You're living in the 20th century

I'm guilty of using this expression. _But_, to my credit ...

I have repeatedly commended BSD on being both a 20th century UNIX
mindset, but still very, very useful today. I recommend it for those
who don't want GNU/Linux's rate of innovation.

Post by Steve Litt
You try to explain to them that nothing in your computer usage requires
or can benefit from KDE enough to justify its immensity, and they go
right on with the same set of responses.

Now I'm going to stop you right there.

The only reason I "jumped" on you (fair or not, I did, I admit) was
because you not only said you use QEMU, but BSD didn't do what you
needed. You're kinda the "prime candidate" who _needs_ to learn why
the *d/*ctl services/programs were created. ;)

If you weren't using things that did, then I'd give you 0 (well, maybe
not 0, but almost 0) flak.

Post by Steve Litt
They act personally offended that you're not installing KDE.

Sorry, but I call BS on that.

I.e., 98% of sites out there are anti-systemd.

E.g., it's so bad that virtually _everyone_ trying to learn systemd
can_not_ find good info.

Post by Steve Litt
This is what everyday life is like for the person who chooses to forego
systemd, and actually admits it online. We're not talking one critic.
We're not talking five critics. We're talking maybe thirty to fifty
prolific critics on ten different LUG mailing lists, and of course
another twenty on the mailing list of each distro that's chosen systemd.

Dude ... I'm now not on 3 lists because the anti-systemd was so thick.
In the case of 1 list, I know several of us left because we couldn't
help others with their systemd questions.

So ... I think you're seeing the fact that _others_ have made systemd
so "polarizing" that there is now a "backlash" of people who _have_
learned it, and realized, "hey, this stuff isn't so bad."

Post by Steve Litt
You once discussed the phenominon of every last bug being summarily
blamed on systemd. I've seen that happen quite a bit, and it must be
frustrating as hell. "Hey, my cut command doesn't work on Jessie, that
damn systemd broke it!"

Okay, fair enough. I appreciate that admission.

Post by Steve Litt
Now imagine that you're a technologically proficient computer *user*
who just uses his computer to run his business, and you've been using
Linux to run it for a decade. Any virtualization you do is quite well
handled by qemu.

Er, um, sorry, disagree.

You cannot make dynamic changes to networking and firewalls with
legacy solutions, at least not without reloading libvirt and
restarting scripts.

Understand that's why I "jumped in." Because 75%+ of what I've done
for the last 2 years has been QEMU/KVM. And it's why nm, firewalld
and other solutions came to be, as did other *d/*ctl
services/programs.

The days of static scripts are gone _because_ of libvirt, which is
used by QEMU/KVM.

Post by Steve Litt
Because keystrokes are faster than a mouse, and
because you believe screen real estate is valuable, you use Openbox.

Well, in your analogy, I run Fedora, which offers "pure" desktop
modes, and not as off-shoots from the main distro with their own
repos, but as part of the default repo. But, that's another debate.

Post by Steve Litt
You boot once a week, so you don't care whether the boot takes a second
or a minute.

Anyone who argues systemd for boot time needs to be smacked silly.
I'll volunteer to do so. ;)

Post by Steve Litt
You've never in your life seen any boot indeterminancies
that could be caused by the kernel's starting things in parallel, in
indeterminate order.

Er, um, sorry, disagree.

In fact, this happens a lot with SysV init -- hangs and other issues
with dependencies.

Going one step further ... Dracut solves such with the initrd as well.

Post by Steve Litt
You would derive no major benefit from systemd.

And, again, I'll disagree because you're relying on libvirt. The only
way we can have deterministic, dynamic libvirt is with systemd and the
new *d/*ctl solutions. The idea that your system is set at "boot" and
at no other time is a joke.

It's a bad joke that was not only not true in the 20th century, but
has become THE main issue in the 21st. Red Hat didn't develop a
replacement for Upstart because it wanted to. It was _forced_ to.

Post by Steve Litt
You want a nice, simple Linux like Debian, so that's what you use. And then
Debian goes systemd, so you switch to Void Linux or Manjaro-OpenRC or
Funtoo or Devuan.

And best of luck there. But I see GNU/Linux being systemd in its
future, out of sheer necessity. Just like those that complained that
we didn't need threaded C libraries.

Post by Steve Litt
And all of a sudden, you're a disempowering anti-innovation neckbeard
stuck in the 20th century who's out of touch and doesn't know the whole
story. And you're being told that by fifty different people. This is
everyday life for the guy who chooses not to use systemd.

Then the history of GNU/Linux is "dis-empowerment." ;)

I mean, seriously. This isn't a new debate. Heck, there were a lot
in the '90s. But there weren't as many users, and most couldn't just
fire off a blog post.

Post by Steve Litt
I don't get it. I use Vim, Barry uses Emacs, we would never switch

Okay, now you're going off-base even further ... and here's the thing.

Can you use SysV init with Upstart?! No! It's not just a "choice."
Init has _never_ been about "choice."

Post by Steve Litt
We recognize that the other
is productive in the environment of his choice.

Which is 100% in-applicable. Sorry, but ... no.

Post by Steve Litt
I use Python, Kevin uses Perl,

Now this is a bit different ...

What if you want to use Perl instead of Python 2.x for the distro's
scripts? You can_not_ in many distros. You're stuck with Python 2.x.

So that is somewhat applicable.

In fact, it _supports_ the fact that ... no ... you actually do _not_
have choice in your init, deployment scripting language, etc... ;)

Post by Steve Litt
we would never switch places, but we don't call each other
names: We recognize that the other is productive in the environment of
his choice. I use Openbox, Joe uses Unity, we would never switch
places, but we don't call each other names: We recognize that the other
is productive in the environment of his choice.

If you're complaining about "name calling," then try being
"knowledgeable" of systemd. You're suddenly not only "the problem,"
but supporting the "anti-Christ of audio." ;)

Dude ... we can play that sad song all day.

All I've asked ... ever asked ... is that people understand what they
are talking about. I didn't go here with you ... until you mentioned
QEMU _and_ why BSD isn't working for you.

So now I'm merely telling you ...

You need to learn the *d/*ctl services/programs ... because you're
using things that they were created to address. ;)

Post by Steve Litt
And then there's this one exception called systemd, where every single
bug is caused by systemd, and everyone not using systemd is an out of
touch neckbeard. I don't get it.

Obviously. ;)

-- bjs

[Steve Litt]

On Tue, 11 Aug 2015 14:12:25 -0400

Post by Bryan J Smith
Anyone who argues systemd for boot time needs to be smacked silly.
I'll volunteer to do so. ;)

Oh, man, we're going to make a lot of money with this:

http://0pointer.de/blog/projects/systemd.html

A few selected quotes:

======================================
For a fast and efficient boot-up two things are crucial:
======================================

======================================
if we manage to make those sockets available for connection earlier and
only actually wait for that instead of the full daemon start-up, then
we can speed up the entire boot and start more processes in parallel.
======================================

======================================
nd that is actually a really ingenious design, and the primary reason
why MacOS manages to provide the fantastic boot-up times it provides. I
can highly recommend this video where the launchd folks explain what
they are doing. Unfortunately this idea never really took on outside of
the Apple camp.
======================================

======================================
Another thing we can learn from the MacOS boot-up logic is that shell
scripts are evil. Shell is fast and shell is slow. It is fast to hack,
but slow in execution.
======================================

======================================
More importantly however, it is also our plan to experiment with
systemd not only for optimizing boot times, but also to make it the
ideal session manager, to replace (or possibly just augment)
gnome-session, kdeinit and similar daemons.
======================================

======================================
Hence it will not take advantage of the full socket and bus-based
parallelization pointed out above, however it will interpret the
parallelization hints from the LSB headers, and hence boots faster than
the Upstart system,
======================================

======================================
However, they are completely unscientific as they are measured for a VM
(single CPU) and by using the stop timer in my watch. Fedora 13 booting
up with Upstart takes 27s, with systemd we reach 24s (from grub to gdm,
same system, same settings, shorter value of two bootups, one
immediately following the other).
======================================

We can rent out a stadium, sell tickets for $50/tickets, offer a
pay-per-view, and probably make money on trademarked goods as you smack
Lennart silly. We can go into partnership, and offer a lot more branded
merchandise and popular FOSS events. Only thing is, if we become
partners, we'll communicate on phone and in person, not via email,
OK? :-)

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

[Bryan J Smith]

Steve ...

The post is from 2010 and _pre-faced_ by this statement ...

"Upstart, which has by now found its way into all major distributions."

In other words ...

This was a change Upstart had already driven, and was _expected_ ...
parallelism.

Context my friend, context. ;)

-- bjs

Post by Steve Litt
On Tue, 11 Aug 2015 14:12:25 -0400

Post by Bryan J Smith
Anyone who argues systemd for boot time needs to be smacked silly.
I'll volunteer to do so. ;)

http://0pointer.de/blog/projects/systemd.html
======================================
======================================
======================================
if we manage to make those sockets available for connection earlier and
only actually wait for that instead of the full daemon start-up, then
we can speed up the entire boot and start more processes in parallel.
======================================
======================================
nd that is actually a really ingenious design, and the primary reason
why MacOS manages to provide the fantastic boot-up times it provides. I
can highly recommend this video where the launchd folks explain what
they are doing. Unfortunately this idea never really took on outside of
the Apple camp.
======================================
======================================
Another thing we can learn from the MacOS boot-up logic is that shell
scripts are evil. Shell is fast and shell is slow. It is fast to hack,
but slow in execution.
======================================
======================================
More importantly however, it is also our plan to experiment with
systemd not only for optimizing boot times, but also to make it the
ideal session manager, to replace (or possibly just augment)
gnome-session, kdeinit and similar daemons.
======================================
======================================
Hence it will not take advantage of the full socket and bus-based
parallelization pointed out above, however it will interpret the
parallelization hints from the LSB headers, and hence boots faster than
the Upstart system,
======================================
======================================
However, they are completely unscientific as they are measured for a VM
(single CPU) and by using the stop timer in my watch. Fedora 13 booting
up with Upstart takes 27s, with systemd we reach 24s (from grub to gdm,
same system, same settings, shorter value of two bootups, one
immediately following the other).
======================================
We can rent out a stadium, sell tickets for $50/tickets, offer a
pay-per-view, and probably make money on trademarked goods as you smack
Lennart silly. We can go into partnership, and offer a lot more branded
merchandise and popular FOSS events. Only thing is, if we become
partners, we'll communicate on phone and in person, not via email,
OK? :-)
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Bryan J Smith]

Post by Bryan J Smith
I.e., 98% of sites out there are anti-systemd.
E.g., it's so bad that virtually _everyone_ trying to learn systemd
can_not_ find good info.

I also want to point out that some very long-time Debian people who
were merely offering systemd as an "option" -- well _before_ the vote
-- were getting constantly "kicked the crotch" by the rabid users.

Tollef was one of the best known, who finally said "enough," and
dropped all maintainership of systemd. In other words ... the tactic
of far too many of the anti-systemd crowd was to lambast and make it
extremely difficult for anyone doing systemd at all ...

Even well before the Debian vote! [1]

But just to look at the "bigger picture" ...

For those that don't know, in late 2013, several Debian Maintainers
setup a series of VM environments so _all_ Debian Maintainers can
compare. There were several maintainers who posted various analysis
of SysV init, including implementations like OpenRC, against Upstart
and systemd.

One of the best ones came from Russ Allbery. [2]

--- BEGIN QUOTE --------------------
"As reported to this bug, I did a fairly extensive evaluation of both
upstart and systemd by converting one of my packages, which provides a
network UDP service, to a native configuration with both systems ...
...
I started this process with the expectation that systemd and upstart would
be roughly evenly matched in capabilities.
...
To my surprise, that's not what happened. Rather, I concluded that
systemd has a substantial technical advantage over upstart, primarily in
terms of available useful features, but also in terms of fundamental
design.
--- END QUOTE --------------------

But that all doesn't matter, right?
As Steve says ... SysV init wasn't broke, right? ;)

Post by Bryan J Smith
Anyone who argues systemd for boot time needs to be smacked silly.
I'll volunteer to do so. ;)

I'll let Russ led this one ...

--- BEGIN QUOTE --------------------
"I think the OpenRC developers are great people and I wish them all
the success in the world with their project, but I just don't think
it's ambitious enough for Debian's needs. If we're going to the
effort of replacing init systems and changing our startup scripts, a
bare minimum requirement for me is that we at least address the known
weaknesses of the sysvinit mechanism, namely:

* Lack of integration with kernel-level events to properly order startup.
* No mechanism for process monitoring and restarting beyond inittab.
* Heavy reliance on shell scripting rather than declarative syntax.
* A fork and exit with PID file model for daemon startup."
--- END QUOTE --------------------

Now ... where do you see "boot time" in there? ;)

I'll skip the 3rd one in Russ' list, because that's subjective. Some
people want shell script to continue, and I'm not going to debate that
one.

However ... here are my top 3, which overlap with 3 of Russ' 4.

My #1, which is the 4th one in Russ' list, has always been the fact
that forking in SysV init results in "zombie nation." This is a
_chronic_ flaw with SysV init, and OpenRC only continues.

My #2, which is 1st in Russ' list, is the reality that SysV is
_grossly_ and I mean _grossly_ ignorant of the kernel's startup needs.
If you are wondering why things like dracut was created, udev got
sucked up by systemd and we've finally got a facility like journald,
I'll take you on a tour ... anytime! ;)

My #3, which is 2nd in Russ' list, should be obvious. Upstart
addresses this somewhat. So not only was Upstart a plausible
solution, but Red Hat even adopted it.

And on that last note, understand what Russ said here about Upstart ...

--- BEGIN QUOTE --------------------
"* Red Hat adopted upstart but never did a wholescale conversion, and then
abandoned upstart in favor of systemd. Obviously, one should not put
too much weight on this; Red Hat is a commercial company that has a
wealth of reasons for its actions that do not apply to Debian. But I
think it's still worth noting that the only non-Ubuntu major adopter of
upstart backed away from it.
...
I'm concerned that, if we adopt upstart, in two or three years we'll end
up wanting to do the same thing that Red Hat did, back out, and switch to
systemd. That would be a huge amount of wasted effort. Even worse would
be to end up in that situation and decide that the conversion is too much
work, and then just settle for an init system that is harder to integrate
and provides less functionality."
--- END QUOTE --------------------

Red Hat was the _only_, major non-Ubuntu distro to adopt Upstart. At
the time, Red Hat had no less than three (3) init replacements in
development, but decided to use Canonical's Upstart. That says
something ... especially when no one else did ... not SuSE, not anyone
else of any size.

Then Red Hat backed away. Why was that? Could it be that it didn't
solve various _needs_? ;)

Now let's get to the "other arguments" ...

- journald

--- BEGIN QUOTE --------------------
"* Integrated daemon status. This one caught me by surprise, since the
systemd journal was functionality that I expected to dislike. But I was
surprised at how well-implemented it is, and systemctl status blew me
away. I think any systems administrator who has tried to debug a
running service will be immediately struck by the differences between
upstart ... and systemd:
...
Both are clearly superior to sysvinit, which bails on the problem
entirely and forces reimplementation in every init script, but the
systemd approach takes this to another level. And this is not an easy
change for upstart. While some more data could be added, like the
command line taken from ps, the most useful addition in systemd is the
log summary. And that relies on the journal, which is a fundamental
design decision of systemd.

And yes, all of those log messages are also in the syslog files where
one would expect to find them. And systemd can also capture standard
output and standard error from daemons and drop that in the journal and
from there into syslog, which makes it much easier to uncover daemon
startup problems that resulted in complaints to standard error instead
of syslog. This cannot even be easily replaced with something that
might parse the syslog files, even given output forwarding to syslog
(something upstart currently doesn't have), since the journal will
continue to work properly even if all syslog messages are forwarded off
the host, stored in some other format, or stored in some other file.
systemd is agnostic to the underlying syslog implementation.
--- END QUOTE --------------------

- security (and this doesn't even scratch the surface of containers)

--- BEGIN QUOTE --------------------
"* Security defense in depth. Both upstart and systemd support the basics
(setting the user and group, process limits, and so forth). However,
systemd adds a multitude of additional defense in depth features,
ranging from capability limits to private namespaces or the ability to
deny a job access to the network. This is just a simple matter of
programming on the upstart side, but it still contributes to the general
feature deficit; the capabilities in systemd exist today. I'm sure I'm
not the only systems administrator who is expecting security features
and this sort of defense in depth to become increasingly important over
the next few years.

Here again, I think we have an opportunity for Debian to be more
innovative and forward-looking in what we attempt to accomplish in the
archive by adopting frameworks that let us incorporate the principles of
least privilege and defense in depth into our standard daemon
configurations.
--- END QUOTE --------------------

Read the rest of the Debian list post, because it's extremely _objective_!

Now ... can we get pass the BS, and on to solving _real_ problems?

Or at least talk about Devuan or BSD. I'm always open to such, and
OpenRC. But no more anti-systemd non-sense. Please.

Just my view, and my last on the matter, as I've said enough, and
won't convince anyone who hasn't been already. ;)

-- bjs

[1] "Tollef Fog Heen's blog
Sun, 16 Nov 2014 - Resigning as a Debian systemd maintainer"
- http://err.no/personal/blog/2014/Nov/16

[2] "Bug#727708: init system other points, and conclusion"
- https://lists.debian.org/debian-ctte/2013/12/msg00234.html

[Barry Fishman]

Post by Bryan J Smith

Post by Barry Fishman
<rant>
I think Steve ultimately just want's control over his own computers.
Why is that asking for too much?

And that's the problem.
People have forgotten all the new subsystems in the kernel, all the
new, required "process awareness" between services, all of the
"message passing" things use to communicate, that have been developed
over the last 20+ years.

I can't and don't talk for Steve. I don't care about sysv vs systemd.
I care about solving problems not working around them.

Systemd is more resilient that sysv, and avoids many of its intrinsic
problems. However, when systems become more complex that what sysv can
easily handle you need to consider if maybe something else also needs to
happen.

The Unix kernel handles failures by handing the problem back to the
application level. This works well with simple systems, but if you want
something like the complex system you want, maybe something better needs
to be done.

Just maybe Andrew Tanenbaum, Niklaus Wirth, and Alan Kay were right.
Maybe we need use OS's and system languages that better encapsulate the
kinds of OS primitives we need. Things like "message passing" are
really micro-kernel concepts. Simulating them as network services make
their atomic nature difficult to reproduce, and certainly make for a
less resilient system.

Maybe we need to actually start using our universities to build open
source infrastructure projects again (as was done with Arpanet), rather
than relying on Silicon Valley (and North Carolina) companies that are
only concerned about next quarters profits to set directions.

The Arpanet was justified by the danger of the Soviet Union. Isn't an
internet that cannot preserve the security of government systems like
the recent break in, enough to justify a new effort.

--
Barry Fishman

[Steve Litt]

On Sun, 9 Aug 2015 21:10:16 -0400

Post by Kevin Korb
OTOH, he is also allergic to the concept of a layer of abstraction.

If this were true, I'd still be coding in assembler (yes, I did that
professionally briefly). If this were true, I wouldn't use Python, and
I'd *never* use Python's Yaml or XML parser extensions. If this were
true, I'd never write shellscripts: Heck, I can code it in C.

My actual belief about layers of abstraction is that every one has a
cost, and most have a benefit, at least in certain use cases. I
approach them the way I approach purchasing merchandise: Is it worth
the cost. In the case of the Python XML parsing tools, heck yeah it's
worth the cost, that's the only way I can be guaranteed a high quality,
no compromise way forward to write books destinationed for both PDF and
ePub. In the case of GUI, heck yeah it's worth the cost: It's pretty
hard to make diagrams without it. In the case of drag and drop GUI,
probably not, especially if the cost is the complexity of KDE.

Post by Kevin Korb
That is the root of everything between why he won't use lvm2

I'll probably start using LVM when I start encrypting my drives,
because that's the only benefit *to me*. The idea of rearranging
partitions (or whatever you want to call them) is of no consequence to
me.

Post by Kevin Korb
to why he
thinks 'echo select ..... | mysql | awk ...' is better than using the
appropriate library interface from whichever programming language we
are talking about at the time.

No, that's a different thing. With every new thing you want to do,
there are tens, or maybe hundreds of thing you can evaluate. Assuming
you haven't had one specifically recommended by someone credible, you
just code up your own. It's faster.

By the way, I learned a little trick, which Eric Raymond and Rick Moen
refused to put in "How to Ask Questions the Smart Way" because they
felt it was a little too duplicitous. You know how you ask a question
on a mailing list and nobody answers? (Not necessarily on GoLUG, but
on a lot of mailing lists). Here's how to get an answer every time.
Make some kludge that does it, then brag about it on the mailing list.
*Immediately*, people who didn't answer you sprint to the keyboard to
indignantly tell you about a better way. You pick the best way, and go
with it.

I did this in the Lua mailing list, making a table object to compensate
for Lua's lack of a continue statement to restart the top of a loop.
When complete, I shared the design on the Lua list. One guy commented
"I don't like Steve's design at all, but I think his design is the best
possible proof that Lua needs a continue statement. :-)

Of course, sometimes your kludge turns out to be the best
alternative :-)

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

[Kevin Korb]

lvm and dmcrypt are both based on device mapper but they are
completely different layers. You can either use lvm to slice up or
combine your encrypted volumes or you can encrypt your lvm volumes. I
have done it both ways depending on what I was trying to accomplish at
the time.

Post by Steve Litt

Post by Kevin Korb
OTOH, he is also allergic to the concept of a layer of
abstraction.

If this were true, I'd still be coding in assembler (yes, I did
that professionally briefly). If this were true, I wouldn't use
Python, and I'd *never* use Python's Yaml or XML parser extensions.
If this were true, I'd never write shellscripts: Heck, I can code
it in C.
My actual belief about layers of abstraction is that every one has
a cost, and most have a benefit, at least in certain use cases. I
approach them the way I approach purchasing merchandise: Is it
worth the cost. In the case of the Python XML parsing tools, heck
yeah it's worth the cost, that's the only way I can be guaranteed a
high quality, no compromise way forward to write books
destinationed for both PDF and ePub. In the case of GUI, heck yeah
it's worth the cost: It's pretty hard to make diagrams without it.
In the case of drag and drop GUI, probably not, especially if the
cost is the complexity of KDE.

Post by Kevin Korb
That is the root of everything between why he won't use lvm2

I'll probably start using LVM when I start encrypting my drives,
because that's the only benefit *to me*. The idea of rearranging
partitions (or whatever you want to call them) is of no consequence
to me.

Post by Kevin Korb
to why he thinks 'echo select ..... | mysql | awk ...' is better
than using the appropriate library interface from whichever
programming language we are talking about at the time.

No, that's a different thing. With every new thing you want to do,
there are tens, or maybe hundreds of thing you can evaluate.
Assuming you haven't had one specifically recommended by someone
credible, you just code up your own. It's faster.
By the way, I learned a little trick, which Eric Raymond and Rick
Moen refused to put in "How to Ask Questions the Smart Way" because
they felt it was a little too duplicitous. You know how you ask a
question on a mailing list and nobody answers? (Not necessarily on
GoLUG, but on a lot of mailing lists). Here's how to get an answer
every time. Make some kludge that does it, then brag about it on
the mailing list. *Immediately*, people who didn't answer you
sprint to the keyboard to indignantly tell you about a better way.
You pick the best way, and go with it.
I did this in the Lua mailing list, making a table object to
compensate for Lua's lack of a continue statement to restart the
top of a loop. When complete, I shared the design on the Lua list.
One guy commented "I don't like Steve's design at all, but I think
his design is the best possible proof that Lua needs a continue
statement. :-)
Of course, sometimes your kludge turns out to be the best
alternative :-)
SteveT
Steve Litt July 2015 featured book: Rapid Learning for the 21st
Century http://www.troubleshooters.com/rl21
_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Patrick]

The list of all Intel Processors that have Virtualization in their hardware:

http://ark.intel.com/Products/VirtualizationTechnology

Post by Bryan J Smith

... hardware-assisted Qemu ... hardware assisted VM ...
... a minimalist system, when used in a minimalist way,
yields a small, modular system quite the opposite of spaghetti.

You made two (2) _mutually_exclusive_ statements.
You want VMs ... but you want a minimal system. There's no way you
can have both.
You either adopt modern, dynamic, deterministic services like systemd,
firewalld, nm and other things that modify and work with libvirt in
real-time,
Or ...
You write a lot of incomprehensible spaghetti code that does the same,
but doesn't work, and is definitely _unsupportable_.
Speaking from working with both Red Hat (2012-2014) and HP (2014-2015)
on libvirt and, even more so, OpenStack, in a very "leading" capacity
-- first as 1 of 3 people handling "enablement" of OpenStack at Red
Hat Enablement, and then as the prime, leading Professional Services
guy for HP OpenStack Professional Services -- I can tell you ...
You either learn the new tools ... you create a lot of spaghetti.
It's your choice. ;)

When a minimalist system is used for huge systems, there can be
problems. I'll speak of that later.

And I have a continued problem with shell scripts for just basic libvirt.
I.e., there's a reason why systemd, firewalld, nm, etc... facilities
were created by Red Hat.
Now I could understand "your position" if you didn't use QEMU/KVM.
But since you do ... please join the 21st century. ;)
I.e., It's not me saying "my way dammit.' It's me saying, "If you're
on the same highway as me ... please get out of your '59 before you
cause a huge accident."

They'd notice those things if their use case required them. And since
their use case doesn't require them, they don't need them.

Dude ... one subsystem ... libvirt. DONE.

That's an observation based on recent recent changes to some Linux
distros. In 2013, a person wanting only what he needed, with a
not-too-complex use case, was quite satisfied with Debian, as long as
he didn't use Gnome3 or KDE. The person didn't change, his requirements
didn't change, his use case didn't change: Debian changed. So he
migrated to something like what Debian was in 2013. There are still
plenty of them around, in both Linux and BSD incarnations.

Because Debian's massive installed userbases said ... "If you're going
to change from SysV init, we want systemd instead of Upstart."
Why? Because Debian's massive installed userbases are running a
crapload of libvirt, and they are tired of the non-sense.
Having to deal with hLinux (HP Linux), based on Debian, I too was
sick'n tired of _lacking_ the _basic_ facilities that Fedora-based
solutions had thanx to systemd, firewalld and nm.
Because trying to statically shell script and even have real-time,
"wake-up" forks of shell scripts, is kinda like trying to use an
abacus as a control system for the Space Shuttle. ;)
Anyone who has had to deal with virtualization -- just even on a
single system -- to change network, firewall and other things as VMs
are running can tell you this. Because shell scripts are a PITA that
should _die_, and should have yesterday.
If Upstart would have been "good enough" to solve this, Fedora and Red
Hat would have just _stuck_ with Upstart. Fedora used it from release
9 until 14. RHEL 6, based on Fedora 12-13, shipped with Upstart. But
Upstart did _not_ address it.
So we have the new, _modular_ *d services and *ctl programs.
If you don't like that ... stick with a solution that can run with
static shell scripts and doesn't include virtualization, containers or
other, modular, dynamic solutions that require _real-time_
interaction.
If you did, I would have _0_ issue with your stance. ;)
But because you went down the QEMU route and virtualization ... you're
part of the problem. You're part of the 98% of screaming masses on
the Internet who I do _not_ want to be talking, and filling up Google
searches with utter BS that is so thick, I think I was in Iowa early
into the primaries. ;)
Because you're head-first, "we know better" than people who have

I've seen minimalist systems that get glommed with so much cruft, to
add features, that they become spaghetti. I was a maintenance
programmer on one such system back in the mid 1980's. Started clean,
acquired too much new stuff added too quick, needed a rewrite.

Which is where libvirt was with shell scripts.

Kmail is certainly an example of a simple system that got weighted down
by all sorts of geegaws and ended up a spaghetti project. I have no
idea what Kmail is like today, because I bailed the second they brought
out the doesn't-work Kmail2. But if they rewrote it (and a lot of KDE),
for all I know it's good today.
Twitter was a semi-simple system quickly assembled in Rails, that began
to need both more features and more scaleability. So they did what
They're rewriting huge hunks of Twitter in Scala.
Minimalist technology is superior for simple systems. If one's lucky
enough that his simple system becomes usefully featureful and widely
used, a rewrite is in order. The smart minimalist puts away time and
money toward the rewrite, just like the smart homeowner banks money for
his next roof replacement.

Traditional virtualization is not simple.
And cloud is even less so.
-- bjs
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Richard F. Ostrow Jr.]

Post by Bryan J Smith
Okay, that's a start.
Just understand I'm a "nice guy." But when you start instigating
situations, and turn around and make claims that are not true, at some
point, I'm going to let you take yourself on a tour of the folly, and
try to point it out.

Fair enough, where applicable. With the EFI issue, you are correct - the
machine is capable of CSM, but CSM has been disabled... and it still
boots. The EFI entry in the firmware does show an entry for gentoo on a
USB device. I did not use efibootmgr to set this (at least not
directly). In fact, here's my current configuration from efibootmgr
(with no parameters):

***@gorgon ~ $ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000
Boot0000* gentoo
HD(1,800,ee000,b738f218-7e4b-46f5-86ec-bf3646027e33)File(\EFI\gentoo\grubx64.efi)

Post by Bryan J Smith
I appreciate your candor and honesty, so I don't want that to go
unnoticed. But I'm still "bothered" by your statements about Areca
(which is from Intel's reference design and RAID firmware), because
you're still misapplying it.

My statements were simply from my own viewpoint taken from what I can
see (or understand) on my end. I make no claims that I am a "certified"
or even "officially educated" (ie, have taken college classes) on the
subject(s). I'm merely a fairly well experienced home maintainer with an
interest in enterprise-level equipment re-purposed for private usage.
It's possible I may have read the benefits of a BBU from a false sales
pitch (that at the time was echoed to multiple sources), and if that's
the case I've been fooled out of maybe $50. I know I've read from
multiple sources that users with a BBU-enabled RAID card can (and
should) safely disable barriers (back when I made that decision), but I
am now reading from multiple sources that that is false. I have a BS in
computer engineering (which is good for knowing high-level architectures
and more specifically microcontrollers), but that tells me nothing of
filesystems, RAID cards/hierarchies, etc - that stuff I've picked up on
my own time and on my own dime. If I disagree with you on something,
it's generally because I think you're not seeing the whole picture
(probably because I have omitted some detail, not because you're
flat-out wrong). It is not my intention to discredit you in any way.

Post by Bryan J Smith
I.e., I've been "thrown under the bus" as a "vendor consultant" or
"vendor enablement tech," only to have to document the issues and, in
the end, prove it was the customer tech that utterly did irresponsible
things.

I wouldn't say I'm in any position to "throw you under the bus."

Post by Bryan J Smith
I don't like being in those situations, because _no_one_ wins. Of
course, don't be with another vendor when you do this, because I will
get you laughed out of the room ... and your contract not renewed.

No risk of this - out of my lane.

Post by Bryan J Smith
I can be your friend ... or the documentor of your worst practices,
especially when you force me to do the latter because you keep making
statements and rationales for doing something irresponsible with my
vendor's product.

I might not know enough to know that I am doing anything "irresponsible"
in this case.

[Bryan J Smith]

Post by Richard F. Ostrow Jr.
With the EFI issue, you are correct - the
machine is capable of CSM, but CSM has been disabled...
and it still boots.

Disabled? Or attempted 2nd?

I've seen people claim their CSMs are "disabled," yet when I pull up
their firmware, it's clear it just attempts uEFI first, then loads an
uEFI CSM second.

Post by Richard F. Ostrow Jr.
The EFI entry in the firmware does show an entry for gentoo
on a USB device.
I did not use efibootmgr to set this (at least not directly). In fact,
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000
Boot0000* gentoo
HD(1,800,ee000,b738f218-7e4b-46f5-86ec-bf3646027e33)File(\EFI\gentoo\grubx64.efi)

First off, understand efibootmgr _will_ list _legacy_ BIOS boot entries too. ;)
Secondly, understand uEFI will _skip_ untargetable devices, such as if
your installer created that entry for your Areca. ;)

So ... what's the _full_ output?

Furthermore ...what's the output of ...
# sfdisk -d (USB device)

That would confirm the UUID is your USB device, and _not_ an entry for
your Areca. ;)

Post by Richard F. Ostrow Jr.
My statements were simply from my own viewpoint taken from
what I can see (or understand) on my end. I make no claims
that I am a "certified" or even "officially educated" (ie, have taken
college classes) on the subject(s).

My certifications and my engineering degree tells me jack. The best
IT people often have _neither_. ;)

Post by Richard F. Ostrow Jr.
I'm merely a fairly well experienced home maintainer with an interest in
enterprise-level equipment re-purposed for private usage. It's possible I
may have read the benefits of a BBU from a false sales pitch (that at the
time was echoed to multiple sources), and if that's the case I've been
fooled out of maybe $50. I know I've read from multiple sources that users
with a BBU-enabled RAID card can (and should) safely disable barriers
(back when I made that decision), but I am now reading from multiple
sources that that is false.

BBUs, even just some capacitance, are a good move in general. They
mitigate the issue of unflushed buffers from the on-board SRAM/DRAM of
the board, as well as powering the logic on drives (in some
implementations) to ensure the drive's on-board SRAM/DRAM is flushed
to platter too.

But that doesn't help the case where the OS buffer in the system DRAM
hasn't flushed or otherwise hasn't been committed. When you have
writeback enabled, there's no guarantee it will be flushed with the
vm.dirty_* tuneables trip either.

[ BS = Guilty of going through of the VFS code over the years ]

Beyond that, Device Mapper -- which includes LVM (DM-LVM2 in 2.6+) and
other things outside of the file system code also has its own commits.
But that's another story too.

With NAND devices, this is only going to get worse. The 500+GB
devices have 256MiB-1GiB of DRAM internally, and NAND is slow when it
comes to EEPROM writes.

So we're almost reaching a point where the OS-system-storage is going
to have to have some sorts of "centralized NVRAM," instead of 8GiB
here, 2GiB there, etc... of redundant, volatile (or at least
partially, non-capicitance-backed) DRAM.

Post by Richard F. Ostrow Jr.
I have a BS in computer engineering (which is good for
knowing high-level architectures and more specifically microcontrollers),

I have an EE with Computer option that basically taught me
semiconductor design and other things. Most of this is useless for
even many embedded concepts.

I've _never_ held my certs or degrees over anyone. They don't mean
jack, for the most part. At most, my Red Hat certifications are the
equivalent of having about 8 days of "hands-on, lab-based interviews."

Post by Richard F. Ostrow Jr.
but that tells me nothing of filesystems, RAID cards/hierarchies, etc
- that stuff I've picked up on my own time and on my own dime.

Because actual implementation is far from an engineering ideal or
concise definition. ;)

Post by Richard F. Ostrow Jr.
If I disagree with you on something, it's generally because I think
you're not seeing the whole picture

I would actually differ with you 180 degrees on that ...

I.e., I think it's you who's not seeing the whole picture, at least at
first. But I do enjoy watching yourself disclose more and more until
the whole picture is there, and you see it for yourself. ;)

Post by Richard F. Ostrow Jr.
(probably because I have omitted some detail, not because you're
flat-out wrong). It is not my intention to discredit you in any way.

As I said ... I sit back and just watch the whole thing unfold. ;)

Post by Richard F. Ostrow Jr.
I wouldn't say I'm in any position to "throw you under the bus."

I know. But just understand the parallels it invokes. ;)

I also don't like it when people (not you) say things about Upstream
projects, when it was their own failings, not the software. So that
causes me to "trip" to a certain "attitude" that has gotten me "into
trouble" on various lists.

Post by Richard F. Ostrow Jr.
No risk of this - out of my lane.
I might not know enough to know that I am doing anything "irresponsible" in
this case.

You're only affecting your own systems.

-- bjs

[Richard F. Ostrow Jr.]

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
With the EFI issue, you are correct - the
machine is capable of CSM, but CSM has been disabled...
and it still boots.

Disabled? Or attempted 2nd?
I've seen people claim their CSMs are "disabled," yet when I pull up
their firmware, it's clear it just attempts uEFI first, then loads an
uEFI CSM second.

As far as I can tell, it's disabled. If the vendor implementation
ignores that setting and attempts CSM second (even if I've disabled it
in the firmware), that's possible.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
The EFI entry in the firmware does show an entry for gentoo
on a USB device.
I did not use efibootmgr to set this (at least not directly). In fact,
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000
Boot0000* gentoo
HD(1,800,ee000,b738f218-7e4b-46f5-86ec-bf3646027e33)File(\EFI\gentoo\grubx64.efi)

First off, understand efibootmgr _will_ list _legacy_ BIOS boot entries too. ;)
Secondly, understand uEFI will _skip_ untargetable devices, such as if
your installer created that entry for your Areca. ;)
So ... what's the _full_ output?

erm... that _is_ the full output. I didn't miss anything when I
cut/pasted from my terminal. Is there another parameter besides "-v"
that I should be using to get more output?

Post by Bryan J Smith
Furthermore ...what's the output of ...
# sfdisk -d (USB device)
That would confirm the UUID is your USB device, and _not_ an entry for
your Areca. ;)

Well.. I don't see how that command shows a UUID, but here's the output
(note that the output appears flat-out wrong, as this is a 8GB device):

gorgon rich # sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 1, size= 15636863, Id=ee
/dev/sda2 : start= 0, size= 0, Id= 0
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0

I can do a parted printout:

gorgon rich # parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Kingston DataTraveler 108 (scsi)
Disk /dev/sda: 8006MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 500MB 499MB fat32 ESP boot, esp
2 500MB 8006MB 7506MB btrfs primary

An ls -l /dev/disk/by-uuid | grep sda shows the following UUIDs:

gorgon rich # ls -l /dev/disk/by-uuid/ | grep sda
lrwxrwxrwx 1 root root 9 Aug 9 14:20 2013-12-12-00-56-55-00 ->
../../sda
lrwxrwxrwx 1 root root 10 Aug 9 14:20 25DD-C6EA -> ../../sda1
lrwxrwxrwx 1 root root 10 Aug 9 14:20
8d67ec4c-a141-460f-af90-2ade78250ce9 -> ../../sda2

... from which I can find no evidence of in that efibootmgr entry. If
that line is in fact a UUID entry (I cannot find anything in the man
pages that breaks the output down to describe its contents), then it is
an old UUID entry that doesn't match anything currently in the system.
If it's a UUID entry, I'd also say it's malformed, as it's clearly not a
vfat UUID (which are always quite short).

[Bryan J Smith]

Ouch, your distro is shipping an _old_ version of sfdisk. It's only
outputting the emulated MBR of your GPT.

I've found the updated sfdisk command to be the _only_ way to dump/restore
the GPT in a way to that preserves the UUIDs.

Rod's sgdisk works completely different -- I.e. -d is for delete, not dump.

-- bjs

DISCLAIMER: Sent from phone, please excuse any typos
--
Bryan J Smith - Technology Mercenary

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
With the EFI issue, you are correct - the
machine is capable of CSM, but CSM has been disabled...
and it still boots.

Disabled? Or attempted 2nd?
I've seen people claim their CSMs are "disabled," yet when I pull up
their firmware, it's clear it just attempts uEFI first, then loads an
uEFI CSM second.

As far as I can tell, it's disabled. If the vendor implementation ignores
that setting and attempts CSM second (even if I've disabled it in the
firmware), that's possible.
The EFI entry in the firmware does show an entry for gentoo

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
on a USB device.
I did not use efibootmgr to set this (at least not directly). In fact,
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000
Boot0000* gentoo
HD(1,800,ee000,b738f218-7e4b-46f5-86ec-bf3646027e33)File(\EFI\gentoo\grubx64.efi)

First off, understand efibootmgr _will_ list _legacy_ BIOS boot entries too. ;)
Secondly, understand uEFI will _skip_ untargetable devices, such as if
your installer created that entry for your Areca. ;)
So ... what's the _full_ output?

erm... that _is_ the full output. I didn't miss anything when I cut/pasted
from my terminal. Is there another parameter besides "-v" that I should be
using to get more output?
Furthermore ...what's the output of ...

Post by Bryan J Smith
# sfdisk -d (USB device)
That would confirm the UUID is your USB device, and _not_ an entry for
your Areca. ;)

Well.. I don't see how that command shows a UUID, but here's the output
gorgon rich # sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 1, size= 15636863, Id=ee
/dev/sda2 : start= 0, size= 0, Id= 0
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
gorgon rich # parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Kingston DataTraveler 108 (scsi)
Disk /dev/sda: 8006MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 500MB 499MB fat32 ESP boot, esp
2 500MB 8006MB 7506MB btrfs primary
gorgon rich # ls -l /dev/disk/by-uuid/ | grep sda
lrwxrwxrwx 1 root root 9 Aug 9 14:20 2013-12-12-00-56-55-00 -> ../../sda
lrwxrwxrwx 1 root root 10 Aug 9 14:20 25DD-C6EA -> ../../sda1
lrwxrwxrwx 1 root root 10 Aug 9 14:20
8d67ec4c-a141-460f-af90-2ade78250ce9 -> ../../sda2
... from which I can find no evidence of in that efibootmgr entry. If that
line is in fact a UUID entry (I cannot find anything in the man pages that
breaks the output down to describe its contents), then it is an old UUID
entry that doesn't match anything currently in the system. If it's a UUID
entry, I'd also say it's malformed, as it's clearly not a vfat UUID (which
are always quite short).
--
Life without passion is death in disguise
_______________________________________________
Tech mailing list
http://lists.golug.org/listinfo/tech

[Richard F. Ostrow Jr.]

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
It did everything my manual scripts did, and it did it while
following the appropriate standards. It also was a whole lot
easier to maintain, and worked when my scripts started
failing when LVM changed its initrd requirements.

Define "LVM changed its initrd requirements"?

"LVM changed its initrd requirements":

1. System runs reliably with custom-built initrd
2. LVM update comes along, so I integrate it into my custom-built initrd
as always (been through more than 5 iterations with no issues with
previous versions)
3. System no longer boots without manual intervention, ie, a requirement
has changed

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
Sounded like a win-win to me. The only downside is it wasn't quite
as "minimal" as my scripts were...

Okay, I guess that's where I go "face palm."
As a long-time Gentoo lover, _nothing_ is more distracting and, in
many cases, just _wrong_ of an attitude than either the argument of
"minimal" or "optimized." It's kinda like when people say "systemd is
for speeding up boot-times" when systemd was _never_ designed to do
such, but there _can_ be -- although it's largely a legacy argument by
Upstart (which systemd only "claims" because of that past Upstart
"marketing").
So ... I'll use my long-stnading, classic "Ricer v. Corvette" argument.
Sure, you can drop a lot of money into a "Ricer" and tune the heck out
of it. And you can think you're "cool." But there's still the
realities of ...
- You've spend far _more_ than a Corvette
- You're still accelerating a lot _slower_ than a Corvette**
- You're still handling far _worse_ than a Corvette
- You're getting far _worse_ gas mileage than a Corvette
- You still do a lot of things _worse_ than Corvette (especially torque)
- Etc...
**I'll make an exception for Nitrous v. non-Nitrous, although a
Nitrous Corvette is unreal ... especially with the overhead GM gives
the LS series of engines (to reach 100K mile warranties).
Heck, even the new, supercharged C7 Z06 doesn't even have a gas
guzzler tax (with manual transmission), while the Genesis R Spec gets
worse gas mileage, but "plays games" to avoid it (something Hyundai
has had to revise in the past, and has paid fines for).
So ... please excuse me if the "minimal" argument doesn't go very far
with me, just like the "optimized" argument too.
I.e., you're limiting yourself and causing yourself headaches for
often _0_ benefit, or even _reduced_ performance. ;)

My argument was _not_ for performance-tuning (which would be ridiculous
for maybe a couple of seconds (at absolute best) reduction in boot
time), but because my custom initrd was minimal, easily understood
(fewer variables to track) and traceable. There was _very_ little inside
of it, and what little there was I could usually explain exactly how it
worked and did what it did. For me, this was good - I understood exactly
how the system booted, what it needed, and where to look if something
went wrong. I'll confess that with LVM (when I introduced it to my
systems), the ball game changed a bit - I couldn't find _exactly_ what
LVM wanted, _exactly_ what it did, etc. - I just trusted (blindly,
perhaps... although a lot of interweb pages supported this) that a
statically-linked LVM binary would do the job with the right parameters
- which it did until further down the line. My best guess is that some
device node was needed after the update and was not in my initrd, but I
was unable to find any evidence of what was missing or why it was
failing. Given that I couldn't track/trace/dissect LVM (at least with my
level of experience), my minimalist argument falls on its face, and even
though dracut is not "minimalist" (I haven't the faintest idea how much
of it is structured, and its init script appears to be binary and
unreadable), it seems to reliably get the job done.

[Bryan J Smith]

Post by Richard F. Ostrow Jr.

Post by Bryan J Smith
Define "LVM changed its initrd requirements"?

1. System runs reliably with custom-built initrd
2. LVM update comes along, so I integrate it into my custom-built initrd as
always (been through more than 5 iterations with no issues with previous
versions)
3. System no longer boots without manual intervention, ie, a requirement has
changed

I have no idea what any of that means.

Post by Richard F. Ostrow Jr.
My argument was _not_ for performance-tuning (which would
be ridiculous for maybe a couple of seconds (at absolute best)
reduction in boot time),

I know, but other, fellow Gentoo users often start that garbage.
Normally most Fedora or Ubuntu users don't know what they are talking
about, but I -- a long-time Gentoo advocate myself -- _do_, and
quickly _dismiss_ it as non-sense with point-by-point rebuttals and,
more importantly, _specific_ examples. ;)

Post by Richard F. Ostrow Jr.
but because my custom initrd was minimal, easily understood (fewer
variables to track) and traceable. There was _very_ little inside of it ...

And this is the other, Gentoo argument.
In reality ... it's utterly _unsupportable_.
And "unsupportable" means breakage and issues.

As I said ... my time is precious.

-- bjs

[Richard F. Ostrow Jr.]

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.

Post by Bryan J Smith
Define "LVM changed its initrd requirements"?

1. System runs reliably with custom-built initrd
2. LVM update comes along, so I integrate it into my custom-built initrd as
always (been through more than 5 iterations with no issues with previous
versions)
3. System no longer boots without manual intervention, ie, a
requirement has
changed

I have no idea what any of that means.

It's simple enough, but it's not traceable any further than this at this
point. I don't expect an answer/solution here (particularly with data
this rough), I'm merely describing my experience.

Post by Bryan J Smith

Post by Richard F. Ostrow Jr.
My argument was _not_ for performance-tuning (which would
be ridiculous for maybe a couple of seconds (at absolute best)
reduction in boot time),

I know, but other, fellow Gentoo users often start that garbage.
Normally most Fedora or Ubuntu users don't know what they are talking
about, but I -- a long-time Gentoo advocate myself -- _do_, and
quickly _dismiss_ it as non-sense with point-by-point rebuttals and,
more importantly, _specific_ examples. ;)

Post by Richard F. Ostrow Jr.
but because my custom initrd was minimal, easily understood (fewer
variables to track) and traceable. There was _very_ little inside of it ...

And this is the other, Gentoo argument.
In reality ... it's utterly _unsupportable_.
And "unsupportable" means breakage and issues.
As I said ... my time is precious.

Wasn't expecting an "answer"/solution on that one either. All I'll say
is that it used to be supportable for simple systems... but when you
introduce LVM, it's no longer supportable as the resources are not
available to answer the obvious questions (what is required, for
instance). To a lesser extent, the same is true of udev... although for
simple systems, you could get away with being ignorant of that.

In my case, I enjoyed knowing what was going on under the hood - it was
an educational experience. But when the data is simply not available,
it's not realistic to really know what's going on. The only real option
left to you is to poke around the source code for LVM or dracut - they
work, and they are open source... it's just not well documented for
these corner cases.

[Bryan J Smith]

Post by Steve Litt
When shopping for components for my current daily driver about a year
ago, I decided to have my root partition on an SSD, and at the time was
256GB.

I was able to nab a Crucial m500 240GB mSATA (2x1.2") card for $110
(IIRC) in late 2013. But under $60 for 240GB is finally getting to
under $0.25/GB.

Post by Steve Litt
sda 8:0 0 223.6G 0 disk
└─sda1 8:1 0 223.6G 0 part /

Well, I'll say this ... if your partition table gets nuked, it's not
hard to re-create it. ;)

And now I see your strategy ...

Post by Steve Litt
├─sdb2 8:18 0 58.6G 0 part /s

sex

Post by Steve Litt
├─sdb3 8:19 0 58.6G 0 part /d

drugs

Post by Steve Litt
├─sdb5 8:21 0 19.5G 0 part /classic/a
├─sdb6 8:22 0 19.5G 0 part /classic/b
├─sdb7 8:23 0 19.5G 0 part /classic/c

[Classic] Rock'n Roll ...

Your A-B-Cs ;)

Of course, this is your big'uns ...

Post by Steve Litt
├─sdb8 8:24 0 117.2G 0 part /home/slitt/mail/Maildir

I was going to say probably 60% of that is from me.

But then again I forgot you used the "BS compression" device for me to
save on space ... /dev/null ;)

-- bjs

[Kevin Korb]

ROFL, I was going to tell Steve that he is so trapped in the past that
he is trying to emulate DOS drive letters in Linux but I made that
argument before and he acted like he knew Linux so much better than I
did that I couldn't possibly understand what he was doing. Then he
told me that he refuses to store anything in his home directory that
isn't an automatically created .file or required to be in ~ .file. I
can only assume that this is the attitude of a person who is both
trapped in the DOS concept of drive letters and completely oblivious
to the idea of more than one person using a single computer.

Post by Bryan J Smith

Post by Steve Litt
When shopping for components for my current daily driver about a
year ago, I decided to have my root partition on an SSD, and at
the time was 256GB.

I was able to nab a Crucial m500 240GB mSATA (2x1.2") card for
$110 (IIRC) in late 2013. But under $60 for 240GB is finally
getting to under $0.25/GB.

Post by Steve Litt
So here's what I did: sda 8:0 0 223.6G 0 disk └─sda1
8:1 0 223.6G 0 part /

Well, I'll say this ... if your partition table gets nuked, it's
not hard to re-create it. ;)
And now I see your strategy ...

Post by Steve Litt
├─sdb2 8:18 0 58.6G 0 part /s

sex

Post by Steve Litt
├─sdb3 8:19 0 58.6G 0 part /d

drugs

Post by Steve Litt
├─sdb5 8:21 0 19.5G 0 part /classic/a ├─sdb6 8:22 0
19.5G 0 part /classic/b ├─sdb7 8:23 0 19.5G 0 part
/classic/c

[Classic] Rock'n Roll ...
Your A-B-Cs ;)
Of course, this is your big'uns ...

Post by Steve Litt
├─sdb8 8:24 0 117.2G 0 part /home/slitt/mail/Maildir

I was going to say probably 60% of that is from me.
But then again I forgot you used the "BS compression" device for me
to save on space ... /dev/null ;)
-- bjs
_______________________________________________ Tech mailing list

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
Kevin Korb Phone: [phone]
Systems Administrator Internet:
FutureQuest, Inc. ***@FutureQuest.net (work)
Orlando, Florida ***@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~

[Steve Litt]

On Thu, 30 Jul 2015 21:22:04 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
ROFL, I was going to tell Steve that he is so trapped in the past that
he is trying to emulate DOS drive letters in Linux but I made that
argument before and he acted like he knew Linux so much better than I
did that I couldn't possibly understand what he was doing.

That's not what happened. I just moved my Windows data organization
over to Linux, as was. So d: became /d.

Then he
told me that he refuses to store anything in his home directory that
isn't an automatically created .file or required to be in ~ .file.

Precisely right. Excluding my email, I could lose my home directory and
lose no data. Keep in mind, this isn't being used as a multiuser
computer: I use it as a Personal Computer not much differently from how
I used my 1986 286 with DOS 3.3. /home/slitt's main job in life is to
house configurations and cache various apps have thrown at it, and
offer up a mount point for my email.

I
can only assume that this is the attitude of a person who is both
trapped in the DOS concept of drive letters and completely oblivious
to the idea of more than one person using a single computer.

I'm sure oblivious to the idea of more than one person using ***my***
computer, but then again, when other people do, they have their
own /home/sylvia directory, and believe me, they won't be using any of
the Steve Litt created programs in /d/bats. Yeah, have fun with *that*
directory name.

And when I back up /d, I get *my* data, not all sorts of cache and
config files and the like.

SteveT

Steve Litt
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21