initrd sizes mushroomed several months ago

[Felix Miata]

# grep MODULES= /etc/initramfs-tools/initramfs.conf
MODULES=dep
# ls -Ggh /boot/initrd.img-[5,6]*
-rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
-rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
-rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
-rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686

Does anyone here have an explanation for the mega-change in size of initrds 
after
kernel 5.17? My initramfs.conf has had MODULES=dep since before testing/bullseye
became testing/bookworm.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Sorry for the misattribution [was: ZFS performance (was: Re: deduplicating file systems: VDO] withDebian?)

[tomas]

On Fri, Nov 11, 2022 at 07:22:19PM +0100, to...@tuxteam.de wrote:

[...]

> I think what hede was hinting at was that early SSDs had a (pretty)
> limited number of write cycles [...]

As was pointed out to me, the OP wasn't hede. It was hw. Sorry for the
mis-attribution.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?)

[David Christensen]

On 11/11/22 00:43, hw wrote:

On Thu, 2022-11-10 at 21:14 -0800, David Christensen wrote:

On 11/10/22 07:44, hw wrote:

On Wed, 2022-11-09 at 21:36 -0800, David Christensen wrote:

On 11/9/22 00:24, hw wrote:
   > On Tue, 2022-11-08 at 17:30 -0800, David Christensen wrote:



Taking snapshots is fast and easy.  The challenge is deciding when to
destroy them.


That seems like an easy decision, just keep as many as you can and destroy the
ones you can't keep.



As with most filesystems, performance of ZFS drops dramatically as you 
approach 100% usage.  So, you need a data destruction policy that keeps 
storage usage and performance at acceptable levels.



Lots of snapshots slows down commands that involve snapshots (e.g.  'zfs 
list -r -t snapshot ...').  This means sysadmin tasks take longer when 
the pool has more snapshots.




I have considered switching to one Intel Optane Memory
Series and a PCIe 4x adapter card in each server [for a ZFS cache].


Isn't that very expensinve and wears out just as well?  



The Intel Optane Memory Series products are designed to be cache devices 
-- when using compatible hardware, Windows, and Intel software.  My 
hardware should be compatible (Dell PowerEdge T30), but I am unsure if 
FreeBSD 12.3-R will see the motherboard NVMe slot or an installed Optane 
Memory Series product.



Intel Optane Memory M10 16 GB PCIe M.2 80mm are US $18.25 on Amazon.


Intel Optane Memory M.2 2280 32GB PCIe NVMe 3.0 x2 are US $69.95 on Amazon.



Wouldn't it be better to have the cache in RAM?



Adding memory should help in more ways than one.  Doing so might reduce 
ZFS cache device usage, but I am not certain.  But, more RAM will not 
address the excessive wear problems when using a desktop SSD as a ZFS 
cache device.



8 GB ECC memory modules to match the existing modules in my SOHO server 
are $24.95 each on eBay.  I have two free memory slots.




Please run and post the relevant command for LVM, btrfs, whatever.


Well, what would that tell you?



That would provide accurate information about the storage configuration 
of your backup server.



Here is the pool in my backup server.  mirror-0 and mirror-1 each use 
two Seagate 3 TB HDD's.  dedup and cache each use partitions on two 
Intel SSD 520 Series 180 GB SSD's:


2022-11-11 20:41:09 toor@f1 ~
# zpool status p1
  pool: p1
 state: ONLINE
  scan: scrub repaired 0 in 7 days 22:18:11 with 0 errors on Sun Sep  4 
14:18:21 2022

config:

NAME  STATE READ WRITE CKSUM
p1ONLINE   0 0 0
  mirror-0ONLINE   0 0 0
gpt/p1a.eli   ONLINE   0 0 0
gpt/p1b.eli   ONLINE   0 0 0
  mirror-1ONLINE   0 0 0
gpt/p1c.eli   ONLINE   0 0 0
gpt/p1d.eli   ONLINE   0 0 0
dedup   
  mirror-2ONLINE   0 0 0
gpt/CVCV**D0180EGN-2.eli  ONLINE   0 0 0
gpt/CVCV**7K180EGN-2.eli  ONLINE   0 0 0
cache
  gpt/CVCV**D0180EGN-1.eliONLINE   0 0 0
  gpt/CVCV**7K180EGN-1.eliONLINE   0 0 0

errors: No known data errors



I suggest creating a ZFS pool with a mirror vdev of two HDD's.
   If you
can get past your dislike of SSD's,
  add a mirror of two SSD's as a
dedicated dedup vdev.  (These will not see the hard usage that cache
devices get.)
   Create a filesystem 'backup'.  Create child filesystems,
one for each host.  Create grandchild filesystems, one for the root
filesystem on each host.


Huh?  What's with these relationships?



ZFS datasets can be organized into hierarchies.  Child dataset 
properties can be inherited from the parent dataset.  Commands can be 
applied to an entire hierarchy by specifying the top dataset and using a 
"recursive" option.  Etc..



When a host is decommissioned and you no longer need the backups, you 
can destroy the backups for just that host.  When you add a new host, 
you can create filesystems for just that host.  You can use different 
backup procedures for different hosts.  Etc..




   Set up daily rsync backups of the root
filesystems on the various hosts to the ZFS grandchild filesystems.  Set
up zfs-auto-snapshot to take daily snapshots of everything, and retain
10 snapshots.  Then watch what happens.


What do you expect to happen?  



I expect the first full backup and snapshot will use an amount of 
storage that is something less than the sum of the sizes of the source 
filesystems (due to compression).  The second through tenth backups and 
snapshots will each increase the storage usage by something less than 
the sum of the daily churn of the source filesystems.  On day 11, and 
every day thereafter, the oldest 

Re: exim4 vs. frontier.com

[David Wright]

On Thu 10 Nov 2022 at 19:27:06 (+), mike.junk...@att.net wrote:
> I've struggled off and on for months to get outbound mail via exim4 through 
> frontier.com with no joy.

Must be a couple of years now?

> I'm on a single user system using mutt and exim4 plus fetchmail. Inbound is 
> no problem.

Excellent, as I don't use fetchmail myself.

> Outbound I see this in /var/log/exim4/mainlog:
> 554 5.7.1 <>: Sender address rejected: Access denied

The empty <> means that your MAIL FROM: is blank, as it was in May.

> /etc/email-addresses has the proper frontier email address in it.

Mine only has the original comments. My envelope address is
constrained by the smarthosts' operators, so that, for example,
the email address that satisfies my ISP is one that I don't
want any mail sent to as I never check it.

> >From web search I created /etc/exim4/conf.d/rewrite/10_from_rewrite 
> >containing this line:
> *  "$header_from:" F
> This supposedly tells exim4 to set the Envelope header the same as the From 
> header.
> I think Sent = Envelope headers, admittedly not sure about that.

I would be very surprised if you really had to touch files in
/etc/exim4/conf.d/ in order to send mail. Searching the web is
unlikely to be very helpful because AIUI Debian sets up exim in
its own, distinct manner.

> If there is anyone on the list who has exim4 talking to Frontier.com please 
> help.

A simple way of testing whether you're using the correct information
is to try sending an email directly from mutt. You can do this by
adding the following (adjusted) to your muttrc configuration file:

  set   smtp_authenticators="plain"
  set   smtp_pass="myPassWd"
  set   smtp_url="smtp://mikemcclain...@frontier.com@smtp.frontier.com:587"
  set   envelope_from_address="mikemcclain...@frontier.com"
  set   use_envelope_from

I'm assuming that your credentials are mikemcclain...@frontier.com
and myPassWd. The From: header in the email can be different if
you wish—I see you use mike.junk...@att.net here, presumably so
that your incoming mail arrives at that address.

(Particular addresses observed by mutt in the current email
automatically trigger a choice of From: address to use in
any replies I send.)

If you run mutt with   -d 5   added to its commandline, mutt will
write a huge ~/.muttdebug* file that includes its conversation with
the smarthost when you send an email¹. Search for 'Sending message...'
to find the start of the interesting bit. Other important strings
that should follow this are:

  … … 7> AUTH PLAIN ABC… … ← revealing this line is a security risk!
  … … 7< 235 2.7.0 Authentication successful

  … … 7> MAIL FROM:
  … … 7< 250 2.1.0 Ok
  … … RCPT TO:
  … … 7< 250 2.1.5 Ok

  … … Sending message... 0K/0.8K (0%)
  … … 7> DATA

  … … 7< 250 2.0.0 Ok: queued as 123ABC45678
  … … 7> QUIT

  … …  Mail sent.

If and when that works, it should be simple to get exim to send
to the smarthost in the same manner. It should involve only the
two files /etc/exim4/{passwd.client,update-exim4.conf.conf} in
most cases.

(Remove the .muttdebug file as it contains password information.
Certainly don't send it to anybody.)

¹ The debug file makes up for the fact that there's no log in
  /var/log/exim4/ because exim doesn't touch it.

Cheers,
David.

Re: Increased read IO wait times after Bullseye upgrade

[Gareth Evans]

> On 11 Nov 2022, at 16:59, Vukovics Mihály  wrote:
> 
> Hi Gareth,
> 
> dmesg is "clean", there disks are not shared in any way and there is no 
> virtualization layer installed.
> 
Hello, but the message was from Nicholas :)

Looking at your first graph, I noticed the upgrade seems to introduce a broad 
correlation between read and write iowait.  Write wait before the uptick is 
fairly consistent and apparently unrelated to read wait.

Does that suggest anything to anyone?

In your atop stats, one drive (sdc) is ~50% more "busy" than the others, has 
double the number of writes, a higher avq value and lower avio time.  Is it 
normal for raid devices to vary this much?

Is this degree of difference consistent over time?  Might atop stats during 
some eg. fio tests be useful?

Have you done any filesystem checks? 

Thanks,
Gareth

Re: ZFS performance

[Stefan Monnier]

Michael Stone [2022-11-11 14:59:46] wrote:
> On Fri, Nov 11, 2022 at 02:05:33PM -0500, Dan Ritter wrote:
>>300TB/year. That's a little bizarre: it's 9.51 MB/s. Modern
>>high end spinners also claim 200MB/s or more when feeding them
>>continuous writes. Apparently WD thinks that can't be sustained
>>more than 5% of the time.
> Which makes sense for most workloads. Very rarely do people write
> continuously to disks *and never keep the data there to read it
> later*.

And on top of it, only write sequentially (since any head movement
brings that bandwidth down very quickly).


Stefan

Re: removing file??

[Amn]

Thanks folks, I don't know what I did, but I was able to reinstall 
code::blocks. Thank ya'll.


On 2022-11-11 2:58 a.m., Tim Woodall wrote:

On Thu, 10 Nov 2022, Amn wrote:


I did that, but I got this :

jamiil@ArbolOne:~$ sudo apt clean
jamiil@ArbolOne:~$ sudo apt install codeblocks-dev
Reading package lists... Done

snip
?trying to overwrite '/usr/include/codeblocks/Alignment.h', which is 
also in pac

kage codeblocks-headers 20.03
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
?/var/cache/apt/archives/codeblocks-dev_20.03-3.1+b1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



apt-get remove --purge codeblocks-headers

Make sure that doesn't remove stuff you want.

Debian 11 Termit

[Amn]

Does anyone know how to change the color scheme of Termit in Debian 11? 
The files displayed in blue indigo are just too hard to read for me.


Thanks in advance.

Re: Firefox plante régulièrement

[Nicolas Hussein]

Bonsoir,

Le lundi 07 novembre 2022 à 12:53 +0100, ajh-valmer a écrit :
> 
> Je pense qu'il faut abandonner Firefox-esr trop buggué pour le
> Firefox "classique",
> qui lui, n'a pas ses défauts sus-décrits.
> 

En effet, j'ai installé Firefox "classique" depuis le site Mozilla, à
la place de Firefox-esr dans les paquets Debian, et, pour le moment, je
n'ai pas rencontré de crash intempestif. Affaire à suivre...

Bonne soirée,
Nicolas

Re: removing file??

[David Wright]

On Fri 11 Nov 2022 at 13:33:12 (+0100), hede wrote:
> Am 11.11.2022 04:32, schrieb Amn:
> > I am trying to remove this file :
> > '/var/cache/apt/archives/codeblocks-dev_20.03-3_amd64.deb', but after
> > trying, even as a 'su', but I am unable to. Any suggestion how to do
> > this?
> 
> The others are trying to solve the problem on the package layer. But
> if removing such an archive file is not possible even with root
> permissions, this could potentially indicate some more fundamental
> problem. Like errors in the data layer of the partition (broken
> harddisk) or read-only mounts.
> 
> My question would be: _How_ did you try to delete the file with root
> permissions? And what was the result (error message)?

AIUI the file was removed entirely normally, but then immediately
recreated by running the apt install command (which downloaded it again).

> And like others suggested: If you are not familiar with deeper Debian
> system knowledge, the (unstable) SID distribution may not be your best
> option. I'd suggest to use some stable distribution (like Debian
> Bullseye currently).

I'm not convinced that Amn /is/ running sid, or at least intending to.
There again, it's possible they upgraded in frustration because they
couldn't get their bluetooth to work. (I'm no help with BT audio.)

Cheers,
David.

Re: else or Debian (Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?))

[Linux-Fan]

hw writes:


On Thu, 2022-11-10 at 22:37 +0100, Linux-Fan wrote:


[...]


>  If you do not value the uptime making actual (even
>  scheduled) copies of the data may be recommendable over
>  using a RAID because such schemes may (among other advantages)
>  protect you from accidental file deletions, too.

Huh?


RAID is limited in its capabilities because it acts at the file system,  
block (or in case of hardware RAID even disk) level. Copying files can  
operate on any subset of the data and is very flexible when it comes to  
changing what is going to be copied, how, when and where to.


### what

When copying files, its a standard feature to allow certain patterns of file  
names to be exclueded. This allows fine-tuning the system to avoid  
unnecessary storage costs by not duplicating the files of which duplicates  
are not needed (.iso or /tmp files could be an example of files that some  
uses may not consider worth duplicating).


### how

Multiple, well established tools exist for file tree copying. In RAID  
scenarios the mode of operation is integral to the solution.


### where to

File trees are much easier copied to network locations compared to adding a  
“network mirror” to any RAID (although that _is_ indeed an option, DRBD was  
mentioned in another post...).


File trees can be copied to slow target storages without slowing down the  
source file system significantly. On the other hand, in RAID scenarios,  
slow members are expected to slow down the performance of the entire array.  
This alone may allow saving a lot of money. E.g. one could consider copying  
the entire tree of VM images that is residing on a fast (and expensive) SSD  
to a slow SMR HDD that only costs a fraction of the SSD. The same thing is  
not possible with a RAID mirror except by slowing down the write operations  
on the mirror to the speed of the HDD or by having two (or more) of the  
expensive SSDs. SMR drives are advised against in RAID scenarios btw.


### when

For file copies, the target storage need not always be online. You can  
connect it only for the time of synchronization. This reduces the chance  
that line overvoltages and other hardware faults destroy both copies at the  
same time. For a RAID, all drives must be online at all times (lest the  
array becomes degraded).


Additionally, when using files, only the _used_ space matters. Beyond that,  
the size of the source and target file systems are decoupled. On the other  
hand, RAID mandates that the sizes of disks adhere to certain properties  
(like all being equal or wasting some of the storage).


> > Is anyone still using ext4?  I'm not saying it's bad or anything, it  
> > only seems that it has gone out of fashion.

>
> IIRC its still Debian's default.

Hm, I haven't really used Debian in a long time.  There's probably no reason  
to change that.  If you want something else, you can always go for it.


Why are you asking on a Debian list when you neiter use it nor intend to use  
it?



>  Its my file system of choice unless I have 
> very specific reasons against it. I have never seen it fail outside of 
> hardware issues. Performance of ext4 is quite acceptable out of the box. 
> E.g. it seems to be slightly faster than ZFS for my use cases. 
> Almost every Linux live system can read it. There are no problematic 
> licensing or stability issues whatsoever. By its popularity its probably  
> one of the most widely-deployed Linux file systems which may enhance the  
> chance that whatever problem you incur with ext4 someone else has had before...


I'm not sure it's most widespread.  Centos (and Fedora) defaulted to xfs  
quite
some time ago, and Fedora more recently defaulted to btrfs (a while after  
Redhat
announced they would remove btrfs from RHEL altogether).  Centos went down  
the
drain when it mutated into an outdated version of Fedora, and RHEL is  
probably

isn't any better.


~$ dpkg -S zpool | cut -d: -f 1 | sort -u
[...]
zfs-dkms
zfsutils-linux
~$ dpkg -S mkfs.ext4
e2fsprogs: /usr/share/man/man8/mkfs.ext4.8.gz
e2fsprogs: /sbin/mkfs.ext4
~$ dpkg -S mkfs.xfs
xfsprogs: /sbin/mkfs.xfs
xfsprogs: /usr/share/man/man8/mkfs.xfs.8.gz
~$ dpkg -S mkfs.btrfs
btrfs-progs: /usr/share/man/man8/mkfs.btrfs.8.gz
btrfs-progs: /sbin/mkfs.btrfs

Now check with 

I get the following (smaller number => more popular):

87   e2fsprogs
1657 btrfs-progs
2314 xfsprogs
	2903 zfs-dkms 

Surely this does not really measure if people are actually use these  
file systems. Feel free to provide a more accurate means of measurement. For  
me this strongly suggests that the most popular FS on Debian is ext4.



So assuming that RHEL and Centos may be more widespread than Debian because
there's lots of hardware supporting those but not Debian, I wouldn't think  
that

ext4 is most 

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[Linux-Fan]

hw writes:


On Thu, 2022-11-10 at 23:05 -0500, Michael Stone wrote:
> On Thu, Nov 10, 2022 at 06:55:27PM +0100, hw wrote:
> > On Thu, 2022-11-10 at 11:57 -0500, Michael Stone wrote:
> > > On Thu, Nov 10, 2022 at 05:34:32PM +0100, hw wrote:
> > > > And mind you, SSDs are *designed to fail* the sooner the more data  
you

> > > > write
> > > > to
> > > > them.  They have their uses, maybe even for storage if you're so
> > > > desperate,
> > > > but
> > > > not for backup storage.


[...]


Why would anyone use SSDs for backups?  They're way too expensive for that.


I actually do this for offsite/portable backups because SSDs are shock  
resistant (dont lose data when being dropped etc.).


The most critical thing to acknowledge about using SSDs for backups is that  
the data retention time of SSDs (when not powered) is decreasing with each  
generation.


Write endurance has not become critical in any of my SSD uses so far.  
Increasing workloads have also resulted in me upgrading the SSDs. So far I  
always upgraded faster than running into the write endurance limits. I do  
not use the SSDs as caches but as full-blown file system drives, though.


On the current system, the SSDs report having written about 14 TB and are  
specified by the manufacturer for an endurance of 6300 TBW (drive size is 4  
TB). The small (drive size about 240GB) ones I use for backup are much less  
durable. For one of them, the manufacturer claims 306TBW, the other has  
360 TBW specified. I do not currently know how much data I have written to  
them already. As you can see from the sizes, I backup only a tiny subset of  
the data to SSDs i.e. the parts of my data that I consider most critical (VM  
images not being among them...).


[...]

There was no misdiagnosis.  Have you ever had a failed SSD?  They usually  
just

disappear.  I've had one exception in which the SDD at first only sometimes
disappeared and came back, until it disappeared and didn't come back.


[...]

Just for the record I recall having observed this once in a very similar  
fashion. It was back when a typical SSD size was 60 GiB. By now we should  
mostly be past this “SSD fails early with controller fault” issues. It can  
still happen and I still expect SSDs to fail with less notice compared to  
HDDs.


When I had my first (and so far only) disk failure (on said 60G SSD) I  
decided to:


* Retain important data on HDDs (spinning rust) for the time being

* and also implement RAID1 for all important drives

Although in theory running two disks instead of one should increase the  
overall chance of having one fail, no disks failed after this change so  
far.


YMMV
Linux-Fan

öö 


pgp7fF7ksy0yP.pgp
Description: PGP signature

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[Michael Stone]

On Fri, Nov 11, 2022 at 02:05:33PM -0500, Dan Ritter wrote:

300TB/year. That's a little bizarre: it's 9.51 MB/s. Modern
high end spinners also claim 200MB/s or more when feeding them
continuous writes. Apparently WD thinks that can't be sustained
more than 5% of the time.


Which makes sense for most workloads. Very rarely do people write 
continuously to disks *and never keep the data there to read it later*. 
There are exceptions (mostly of the transaction log type for otherwise 
memory-resident data), and you can get write optimized storage, but 
you'll pay more. For most people that's a bad deal, because it would 
mean paying for a level of write endurance that they'll never use.

Re: else or Debian (Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?))

[Michael Stone]

On Fri, Nov 11, 2022 at 09:03:45AM +0100, hw wrote:

On Thu, 2022-11-10 at 23:12 -0500, Michael Stone wrote:

The advantage to RAID 6 is that it can tolerate a double disk failure.
With RAID 1 you need 3x your effective capacity to achieve that and even
though storage has gotten cheaper, it hasn't gotten that cheap. (e.g.,
an 8 disk RAID 6 has the same fault tolerance as an 18 disk RAID 1 of
equivalent capacity, ignoring pointless quibbling over probabilities.)


so with RAID6, 3x8 is 18 instead of 24


you have 6 disks of useable capacity with the 8 disk raid 6, two disks 
worth of parity. 6 disks of useable capacity on a triple redundant 
mirror is 6*3 = 18.

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[Michael Stone]

On Fri, Nov 11, 2022 at 07:15:07AM +0100, hw wrote:

There was no misdiagnosis.  Have you ever had a failed SSD?  They usually just
disappear.


Actually, they don't; that's a somewhat unusual failure mode. I have had 
a couple of ssd failures, out of hundreds. (And I think mostly from a 
specific known-bad SSD design; I haven't had any at all in the past few 
years.) I've had way more dead hard drives, which is typical.



There was no "not normal" territory, either, unless maybe you consider ZFS cache
as "not normal".  In that case, I would argue that SSDs are well suited for such
applications because they allow for lots of IOOPs and high data transfer rates,
and a hard disk probably wouldn't have failed in place of the SSD because they
don't wear out so quickly.  Since SSDs are so well suited for such purposes,
that can't be "not normal" territory for them.  Perhaps they just need to be
more resilient than they are.


You probably bought the wrong SSD. SSDs write in erase-block units, 
which are on the order of 1-4MB. If you're writing many many small 
blocks (as you would with a ZFS ZIL cache) there's significant write 
amplification. For that application you really need a fairly expensive 
write-optimized SSD, not a commodity (read-optimized) SSD. (And in fact, 
SSD is *not* ideal for this because the data is written sequentially and 
basically never read so low seek times aren't much benefit; NVRAM is 
better suited.) If you were using it for L2ARC cache then mostly that 
makes no sense for a backup server. Without more details it's really 
hard to say any more. Honestly, even with the known issues of using 
commidity SSD for SLOG I find it really hard to believe that your 
backups were doing enough async transactions for that to matter--far 
more likely is still that you simply got a bad copy, just like you can 
get a bad hd. Sometimes you get a bad part, that's life. Certainly not 
something to base a religion on.



Considering that, SSDs generally must be of really bad quality for that to
happen, don't you think?


No, I think you're making unsubstantiated statements, and I'm mostly 
trying to get better information on the record for others who might be 
reading.

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[Dan Ritter]

to...@tuxteam.de wrote: 
> 
> I think what hede was hinting at was that early SSDs had a (pretty)
> limited number of write cycles per "block" [1] before failure; they had
> (and have) extra blocks to substitute broken ones and do a fair amount
> of "wear leveling behind the scenes. So it made more sense to measure
> failures along the "TB written" axis than along the time axis.

They still do, and in fact each generation gets worse in terms
of durability while getting better in price/capacity.

Here's Western Digital's cheap line of NVMe SSDs:
https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-blue-nvme-ssd/product-brief-wd-blue-sn570-nvme-ssd.pdf

MTBF is listed as 1.5 million hours... 160 years.

Lifetime endurance is listed as 150TB for the 250GB version, and
300TB for the 500GB version. 600 full writes expected.

Here's the more expensive Red line:
https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-red-ssd/product-brief-western-digital-wd-red-sn700-nvme-ssd.pdf

MTTF: 1.7 million hours. Snicker.

Endurance: 1000TB for the 500GB version, 2000TB for the 1TB
version. A nice upgrade from 600 writes to 2000 writes.

Unrelated, but cool: the 4TB version weighs 10 grams.

-dsr-

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[Dan Ritter]

Jeffrey Walton wrote: 
> On Fri, Nov 11, 2022 at 2:01 AM  wrote:
> >
> > On Fri, Nov 11, 2022 at 07:15:07AM +0100, hw wrote:
> > > On Thu, 2022-11-10 at 23:05 -0500, Michael Stone wrote:
> >... Here's a report
> > by folks who do lots of HDDs and SDDs:
> >
> >   https://www.backblaze.com/blog/backblaze-hard-drive-stats-q1-2021/
> >
> > The gist, for disks playing similar roles (they don't use yet SSDs for bulk
> > storage, because of the costs): 2/1518 failures for SSDs, 44/1669 for HDDs.
> 
> Forgive my ignorance... Isn't Mean Time Before Failure (MTFB) the
> interesting statistic?
> 
> When selecting hardware, like HDD vs SSD, you don't know if and when a
> failure is going to occur. You can only estimate failures using MTBF.
> 
> After the installation and with failure data in hand, you can check if
> the MTBF estimate is accurate. I expect most of the HDD and SSD
> failures to fall within 1 standard deviation of the reported MTBF. And
> you will have some data points that show failure before MTBF, and some
> data points that show failure after MTBF.


You'd like that to be true. I'd like that to be true. What do we
actually see?

Here's Western Digital's new 22TB 7200RPm NAS disk:
https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-red-pro-hdd/product-brief-western-digital-wd-red-pro-hdd.pdf

Claimed MTBF: 1 million hours. Believe it or not, this is par
for the course for high-end disks.

24 hours a day, 365 days a year: 8760 hours per year.
100/8760 = 114 years.

So, no: MTBF numbers must be presumed to be malicious lies.

More reasonable: this drive comes with a 5 year warranty. Treat
that as the expected lifetime, and you'll be somewhat closer to
the truth maybe.

Here's a new number that used to be just for SSDs, but is now
for spinners as well: expected workload (per year) or Total TB
Written (lifetime). For the above disk family, all of them claim
300TB/year. That's a little bizarre: it's 9.51 MB/s. Modern
high end spinners also claim 200MB/s or more when feeding them
continuous writes. Apparently WD thinks that can't be sustained
more than 5% of the time.

-dsr-

Re: Problem with card reader on Debian 11

[tomas]

On Fri, Nov 11, 2022 at 04:38:21PM +0100, Claudia Neumann wrote:
> Hi Tomas,
> 
> 
> Am Freitag, 11. November 2022, 06:54:36 CET schrieb to...@tuxteam.de:
> > On Thu, Nov 10, 2022 at 11:21:21PM +0100, Claudia Neumann wrote:

[...]

Thanks. The only difference I can see is:

[Debian 11]
[...]
> After:
[...]

> Bus 001 Device 008: ID 1f61:0001 Flexocard GmbH VML-GK2 (USB)
[...]
>   iManufacturer   1 Flexocard GmbH
>   iProduct2 VML-GK2 (USB)
>   iSerial 3 2009002

[Debian 10];
[...]
> After:
[...]

> Bus 001 Device 014: ID 1f61:0001
[...]
>   iManufacturer   1
>   iProduct2
>   iSerial 3

This would kind of make sense: the newer kernel has a more complete
USB device database and "knows" the Flexocard device.

Now I see a couple of possibilities. Either the newer drivers are
buggy, or some other program (perhaps courtesy of udev) "thinks" it
has to take care of this USB gadget. To get a clearer idea about the
second, you might try to run "udevadm monitor" while you insert your
device.

Another thing to check is whether any application has /dev/ttyACM0
(that was its name, wasn't it?) open is to query it with `lsof`.

Ah, you might also want to see what parameters this pseudo-serial
interface it has, e.g. `stty -a < /dev/ttyACM0'.

Sorry: if it seems like I'm poking in the dark, then that' perhaps
because I am :-)

Cheers
-- 
tomás


signature.asc
Description: PGP signature

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[tomas]

On Fri, Nov 11, 2022 at 12:53:21PM -0500, Jeffrey Walton wrote:
> On Fri, Nov 11, 2022 at 2:01 AM  wrote:
> >
> > On Fri, Nov 11, 2022 at 07:15:07AM +0100, hw wrote:
> > > On Thu, 2022-11-10 at 23:05 -0500, Michael Stone wrote:
> >... Here's a report
> > by folks who do lots of HDDs and SDDs:
> >
> >   https://www.backblaze.com/blog/backblaze-hard-drive-stats-q1-2021/
> >
> > The gist, for disks playing similar roles (they don't use yet SSDs for bulk
> > storage, because of the costs): 2/1518 failures for SSDs, 44/1669 for HDDs.
> 
> Forgive my ignorance... Isn't Mean Time Before Failure (MTFB) the
> interesting statistic?

I think what hede was hinting at was that early SSDs had a (pretty)
limited number of write cycles per "block" [1] before failure; they had
(and have) extra blocks to substitute broken ones and do a fair amount
of "wear leveling behind the scenes. So it made more sense to measure
failures along the "TB written" axis than along the time axis.

Cheers

[1] In a very sloppy sense: those beasts have big write units, 256K and
up.

-- 
t


signature.asc
Description: PGP signature

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[Jeffrey Walton]

On Fri, Nov 11, 2022 at 2:01 AM  wrote:
>
> On Fri, Nov 11, 2022 at 07:15:07AM +0100, hw wrote:
> > On Thu, 2022-11-10 at 23:05 -0500, Michael Stone wrote:
>... Here's a report
> by folks who do lots of HDDs and SDDs:
>
>   https://www.backblaze.com/blog/backblaze-hard-drive-stats-q1-2021/
>
> The gist, for disks playing similar roles (they don't use yet SSDs for bulk
> storage, because of the costs): 2/1518 failures for SSDs, 44/1669 for HDDs.

Forgive my ignorance... Isn't Mean Time Before Failure (MTFB) the
interesting statistic?

When selecting hardware, like HDD vs SSD, you don't know if and when a
failure is going to occur. You can only estimate failures using MTBF.

After the installation and with failure data in hand, you can check if
the MTBF estimate is accurate. I expect most of the HDD and SSD
failures to fall within 1 standard deviation of the reported MTBF. And
you will have some data points that show failure before MTBF, and some
data points that show failure after MTBF.

Jeff

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[tomas]

On Fri, Nov 11, 2022 at 05:05:51PM -, Curt wrote:
> On 2022-11-11,   wrote:
> >
> > I just contested that their failure rate is higher than that of HDDs.
[...]

> If he prefers extrapolating his anecdotal personal experience to a
> general rule rather than applying a verifiable general rule to his
> personal experience, then there's just nothing to be done for him!
> 
> 
> > I'm out of this thread.

So you lured me in again, you baddy :)

Everyone has right to their prejudices. I cherish mine too. My beef
was rather with being misrepresented myself.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[Curt]

On 2022-11-11,   wrote:
>
> I just contested that their failure rate is higher than that of HDDs.
> This is something which was true in early days, but nowadays it seems
> to be just a prejudice.

If he prefers extrapolating his anecdotal personal experience to a
general rule rather than applying a verifiable general rule to his
personal experience, then there's just nothing to be done for him!


> I'm out of this thread.
>

Re: Increased read IO wait times after Bullseye upgrade

[Vukovics Mihály]

Hi Gareth,

dmesg is "clean", there disks are not shared in any way and there is no 
virtualization layer installed.


On 2022. 11. 11. 17:34, Nicholas Geovanis wrote:

On Fri, Nov 11, 2022, 1:58 AM Vukovics Mihály  wrote:

Hi Gareth,

I have already tried to change the queue depth for the physichal
disks
but that has almost no effect.
There is almost no load on the filesystem, here is 10s sample from
atop.
1-2 write requests but 30-50ms of average io.

DSK |  sdc  | busy 27%  | read   0  | write  2  |
KiB/r  0  | KiB/w  0  |   | MBr/s 0.0  | MBw/s
0.0  | avq 1.83  | avio 38.0 ms  |
DSK |  sdb  | busy 18%  | read   0  | write 1  |
KiB/r  0  | KiB/w  1  |   | MBr/s 0.0 | MBw/s
0.0  | avq 1.63  | avio 52.0 ms  |
DSK |  sde  | busy 18%  | read   0  | write 1  |
KiB/r  0  | KiB/w  1  |   | MBr/s 0.0 | MBw/s
0.0  | avq 1.63  | avio 52.0 ms  |
DSK |  sda  | busy 17%  | read   0  | write 1  |
KiB/r  0  | KiB/w  1  |   | MBr/s 0.0 | MBw/s
0.0  | avq 1.60  | avio 48.0 ms  |


Those numbers for percentage busy seem very high to me for such a low 
rate of IO initiation. Either the blocks being moved are very large 
(not necessarily wrong, maybe just poorly configured for the load) or 
there are other things going on with the drives.


Are the physical drives shared with any other systems? Are multiple 
VMs of whatever type running on the same hardware host?


Another possibility: the drives and or filesystems are thrashing as 
they respond to hardware and/or filesystem problems. Anything 
interesting there in dmsg or logs?



On 2022. 11. 10. 14:32, Gareth Evans wrote:
> On Thu 10 Nov 2022, at 11:36, Gareth Evans
 wrote:
> [...]
>> This assumes the identification of the driver in [3] (below) is
>> anything to go by.
> I meant [1] not [3].
>
> Also potentially of interest:
>
> "Queue depth
>
> The queue depth is a number between 1 and ~128 that shows how
many I/O requests are queued (in-flight) on average. Having a
queue is beneficial as the requests in the queue can be submitted
to the storage subsystem in an optimised manner and often in
parallel. A queue improves performance at the cost of latency.
>
> If you have some kind of storage performance monitoring solution
in place, a high queue depth could be an indication that the
storage subsystem cannot handle the workload. You may also observe
higher than normal latency figures. As long as latency figures are
still within tolerable limits, there may be no problem."
>
>

https://louwrentius.com/understanding-storage-performance-iops-and-latency.html
>
> See
>
> $ cat /sys/block/sdX/device/queue_depth
>
-- 
--

Köszönettel:
Vukovics Mihály


--
--
Köszönettel:
Vukovics Mihály

Re: Increased read IO wait times after Bullseye upgrade

[Nicholas Geovanis]

On Fri, Nov 11, 2022, 1:58 AM Vukovics Mihály  wrote:

> Hi Gareth,
>
> I have already tried to change the queue depth for the physichal disks
> but that has almost no effect.
> There is almost no load on the filesystem, here is 10s sample from atop.
> 1-2 write requests but 30-50ms of average io.
>
> DSK |  sdc  | busy 27%  | read   0  | write  2  |
> KiB/r  0  | KiB/w  0  |   | MBr/s0.0  | MBw/s
> 0.0  | avq 1.83  | avio 38.0 ms  |
> DSK |  sdb  | busy 18%  | read   0  | write 1  |
> KiB/r  0  | KiB/w  1  |   | MBr/s 0.0  | MBw/s
> 0.0  | avq 1.63  | avio 52.0 ms  |
> DSK |  sde  | busy 18%  | read   0  | write 1  |
> KiB/r  0  | KiB/w  1  |   | MBr/s 0.0  | MBw/s
> 0.0  | avq 1.63  | avio 52.0 ms  |
> DSK |  sda  | busy 17%  | read   0  | write 1  |
> KiB/r  0  | KiB/w  1  |   | MBr/s 0.0  | MBw/s
> 0.0  | avq 1.60  | avio 48.0 ms  |
>

Those numbers for percentage busy seem very high to me for such a low rate
of IO initiation. Either the blocks being moved are very large (not
necessarily wrong, maybe just poorly configured for the load) or there are
other things going on with the drives.

Are the physical drives shared with any other systems? Are multiple VMs of
whatever type running on the same hardware host?

Another possibility: the drives and or filesystems are thrashing as they
respond to hardware and/or filesystem problems. Anything interesting there
in dmsg or logs?


On 2022. 11. 10. 14:32, Gareth Evans wrote:
> > On Thu 10 Nov 2022, at 11:36, Gareth Evans 
> wrote:
> > [...]
> >> This assumes the identification of the driver in [3] (below) is
> >> anything to go by.
> > I meant [1] not [3].
> >
> > Also potentially of interest:
> >
> > "Queue depth
> >
> > The queue depth is a number between 1 and ~128 that shows how many I/O
> requests are queued (in-flight) on average. Having a queue is beneficial as
> the requests in the queue can be submitted to the storage subsystem in an
> optimised manner and often in parallel. A queue improves performance at the
> cost of latency.
> >
> > If you have some kind of storage performance monitoring solution in
> place, a high queue depth could be an indication that the storage subsystem
> cannot handle the workload. You may also observe higher than normal latency
> figures. As long as latency figures are still within tolerable limits,
> there may be no problem."
> >
> >
> https://louwrentius.com/understanding-storage-performance-iops-and-latency.html
> >
> > See
> >
> > $ cat /sys/block/sdX/device/queue_depth
> >
> --
> --
> Köszönettel:
> Vukovics Mihály
>
>

Re: Problem with card reader on Debian 11

[Claudia Neumann]

Hi Tomas,


Am Freitag, 11. November 2022, 06:54:36 CET schrieb to...@tuxteam.de:
> On Thu, Nov 10, 2022 at 11:21:21PM +0100, Claudia Neumann wrote:
> > Hi all,
> >
> > I programmed a library to read german electronic health cards from special
> > devices certified in Germany.
> >
> > After an update from Debian 10 to Debian 11 one of these card readers
> > reads only 64 bytes using /dev/ttyACM0. It should read 256 Bytes which it
> > did from 2010 on.
> >
> > Something must have changed from Debian 10 to Debian 11. Is there a
> > configuration where I can change this behaviour? I don't know which
> > package to blame for the change und what kind of Information I should
> > give you.
>
> Hm. Where to start?
>
> Do you have access to one Debian 10 and one Debian 11 installation to
> compare things?

Yes, parallel installation on the same computer as well as installations on 
different
computers.

> The "ttyACM" is a hint that the device ends up as a "modem" (this is not to
> be taken too seriously). Does that happen in both installations?

Yes. Modemmanager is deinstalled.

> One main suspect is, of course, the kernel (mainly the USB modules). Can you
> compare the output of "lsusb" in both installations, perhaps before and
> after inserting the device?

Okay, sse attachments.

> Another hint would be the output of `lsusb -vvv'. Can you identify the
> device in question? Any differences between Debian 10 and 11?

See attachments. The output of lsusb before and after inserting the device and 
the output
of lsusb -vvv. I can not see any real difference. ??

As I said the library can read 256 Bytes from the device on Debian 10. On 
Debian 11 it can
only read 64 Bytes and breaks the transmission.

Best regards

Claudia


> Cheers and good luck
>
> (NOTE: I kept you in CC because I don't know whether you are subscribed,
> if you prefer, I can drop that)

Yes please keep CC.

Before:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 005: ID 0bda:57da Realtek Semiconductor Corp. Built-In Video 
Camera
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card 
Reader Controller
Bus 001 Device 006: ID 413c:2106 Dell Computer Corp. QuietKey Keyboard
Bus 001 Device 004: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4GHz Wireless 
rechargeable vertical mouse [More]
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

After:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 005: ID 0bda:57da Realtek Semiconductor Corp. Built-In Video 
Camera
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card 
Reader Controller
Bus 001 Device 008: ID 1f61:0001 Flexocard GmbH VML-GK2 (USB)
Bus 001 Device 006: ID 413c:2106 Dell Computer Corp. QuietKey Keyboard
Bus 001 Device 004: ID 1ea7:0064 SHARKOON Technologies GmbH 2.4GHz Wireless 
rechargeable vertical mouse [More]
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lsusb -vvv -d 1f61:0001

Bus 001 Device 008: ID 1f61:0001 Flexocard GmbH VML-GK2 (USB)
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass2 Communications
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x1f61
  idProduct  0x0001
  bcdDevice1.07
  iManufacturer   1 Flexocard GmbH
  iProduct2 VML-GK2 (USB)
  iSerial 3 2009002
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0043
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  490mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands (v.25ter)
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  32
  CDC Header:
bcdCDC   1.10
  CDC ACM:
bmCapabilities   0x00
  CDC Union:
bMasterInterface0
bSlaveInterface 1

Re: Firefox plante régulièrement

[Roberto C . Sánchez]

On Mon, Nov 07, 2022 at 09:37:07PM +0100, Nicolas Hussein wrote:
> Le lundi 07 novembre 2022 à 10:39 +0100, Basile Starynkevitch a écrit :
> > 
> > La morale de l'histoire: un ordinosaure de 12 ans reste un
> > ordinosaure, peu adapté pour de la bureautique ou navigation web
> > récente.
> 
> En effet, c'est un âge très vénérable et je vais commencer à envisager
> de le remplacer à moyen terme. De toute façon à plus long terme je dois
> passer de l'ordinateur de bureau à un ordi portable (pour différentes
> raisons logistiques), alors ça peut être l'occasion.
> 
Il y a 6 mois, j'ai changé d'un poste de travail à un portable (avec un
dock USB-C et deux écrans supplémentaires qui étaient auparavant
connectés au poste de travail) et je suis très content. Si je veux
m'asseoir sur le canapé et travailler un peu je peux débrancher le dock,
et s'il me faut les écrans supplementaires je peux m'asseoir à mon
bureau. Le seul souci que j'avias était les lourdes charges de travail.
En ce cas j'utilise une machine au nuage. Aussi, ça me permettre avoir
un portable moins cher parce que le travail local est seulement
bureautique et le travail de développement se faire au nauge.

Salut,

-Roberto

-- 
Roberto C. Sánchez

Re: definiing deduplication

[Stefan Monnier]

>> Arguably this can be considered as a bug in the application (because
>> a failure in the middle could thus result in an inconsistent state).
> A backup programmer or operator does not necessarily have influence on
> such applications.

Indeed it remains a real problem, that can be solved only with
bug reports and patches.

>> if you don't use snapshots, [...] the bug is in the backup
>> process itself.
> The backuper is not to blame if the backupee filesystem cannot make
> snapshots, and anyways snapshots don't completely solve the consistency
> problem of backups.

Presumably the "backuper" is the sysadmin, i.e. the same (group of)
person who chose the filesystem, so I'd say yes the "backuper" is
to blame.

BTW, I can't think of any filesystem that can't do snapshots.  E.g. I use
snapshots with ext4: just ask your block layer to do the snapshot rather
than your filesystem (in my case I use LVM snapshots).

> Having multiple backups of the same backupee reduces the risk to have
> no consistent copy when the backup needs to be restored.

Agreed.


Stefan

Target any service instance when using "PartOf" in a systemd unit file

[Jonathan Marquardt]

Greetings,

I am trying to configure a wildfly daemon to restart whenever postgresql
restarts (which happens sometimes due to Debian's unattended-upgrades).
I tried to solve this by putting "PartOf=postgresql.service" in
/etc/systemd/system/wildfly.service.

The problem is that postgresql.service can have multiple instances like
postgresql@14-main.service and postgresql@15-main.service, as a new
instance is created with each version upgrade. When this happens, the
main service postgresql.service actually isn't being restarted. Is it
possible to configure wildfly to be restarted when ANY of the postgresql
instances restart?

Cheers!

Jonathan
-- 
OpenPGP Key: 47BC7DE83D462E8BED18AA861224DBD299A4F5F3
 https://www.parckwart.de/pgp_key

Re: else or Debian (Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?))

[Dan Ritter]

hw wrote: 
> On Thu, 2022-11-10 at 20:32 -0500, Dan Ritter wrote:
> > Linux-Fan wrote: 
> > 
> > 
> > [...]
> > * RAID 5 and 6 restoration incurs additional stress on the other
> >   disks in the RAID which makes it more likely that one of them
> >   will fail. The advantage of RAID 6 is that it can then recover
> >   from that...
> 
> Disks are always being stressed when used, and they're being stessed as well
> when other types of RAID arrays than 5 or 6 are being rebuild.  And is there
> evidence that disks fail *because* RAID arrays are being rebuild or would they
> have failed anyway when stressed?

Does it matter? The observed fact is that some notable
proportion of RAID 5/6 rebuilds fail because another drive in
that group has failed. The drives were likely to be from the
same cohort of the manufacturer, and to have experienced very
similar read/write activity over their lifetime.

To some extent this can be ameliorated by using disks from
multiple manufacturers or different batches, but there are only
three rotating disk makers left and managing this is difficult
to arrange at scale.


> > Most of the computers in my house have one disk. If I value any
> > data on that disk,
> 
> Then you don't use only one disk but redundancy.  There's also your time and
> nerves you might value.

It turns out to be really hard to fit a second disk in a laptop,
or in a NUC-sized machine.


> >  I back it up to the server, which has 4 4TB
> > disks in ZFS RAID10. If a disk fails in that, I know I can
> > survive that and replace it within 24 hours for a reasonable
> > amount of money -- rather more reasonable in the last few
> > months.
> 
> How do you get a new suitable disk within 24 hours?  For reasonable amounts of
> money?  Disk prices keep changing all the time.

My local store, MicroCenter, has --- 20ish 4TB disks in stock. I
can go get one in an hour.

Amazon will ship me a suitable drive next day or faster -- I
have ordered some items in the morning and received them before
nightfall -- at a lower cost, but at the price of enriching
Bezos.


-dsr-

Re: removing file??

[hede]

Am 11.11.2022 04:32, schrieb Amn:

I am trying to remove this file :
'/var/cache/apt/archives/codeblocks-dev_20.03-3_amd64.deb', but after
trying, even as a 'su', but I am unable to. Any suggestion how to do
this?


The others are trying to solve the problem on the package layer. But if 
removing such an archive file is not possible even with root 
permissions, this could potentially indicate some more fundamental 
problem. Like errors in the data layer of the partition (broken 
harddisk) or read-only mounts.


My question would be: _How_ did you try to delete the file with root 
permissions? And what was the result (error message)?


And like others suggested: If you are not familiar with deeper Debian 
system knowledge, the (unstable) SID distribution may not be your best 
option. I'd suggest to use some stable distribution (like Debian 
Bullseye currently).


regards
hede

Re: removing file??

[Greg Wooledge]

On Fri, Nov 11, 2022 at 07:41:25AM +, Peter von Kaehne wrote:
> To resolve the conflict you need to figure out what is the (other) owner of 
> '/usr/include/codeblocks/Alignment.h'.

It says it right there in the error message.

> >  trying to overwrite '/usr/include/codeblocks/Alignment.h', which is also 
> > in pac
> > kage codeblocks-headers 20.03

Re: removing file??

[Greg Wooledge]

On Thu, Nov 10, 2022 at 11:21:15PM -0500, Amn wrote:
> jamiil@ArbolOne:~$ sudo apt clean
> jamiil@ArbolOne:~$ sudo apt install codeblocks-dev
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following NEW packages will be installed:
>   codeblocks-dev
> 0 upgraded, 1 newly installed, 0 to remove and 322 not upgraded.
> Need to get 522 kB of archives.
> After this operation, 1,905 kB of additional disk space will be used.
> Get:1 http://ftp.de.debian.org/debian sid/main amd64 codeblocks-dev amd64
> 20.03-3.1+b1 [522 kB]

Sid.

> Fetched 522 kB in 2s (313 kB/s)
> (Reading database ... 258020 files and directories currently installed.)
> Preparing to unpack .../codeblocks-dev_20.03-3.1+b1_amd64.deb ...
> Unpacking codeblocks-dev:amd64 (20.03-3.1+b1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/codeblocks-dev_20.03-3.1+
> b1_amd64.deb (--unpack):
>  trying to overwrite '/usr/include/codeblocks/Alignment.h', which is also in
> pac
> kage codeblocks-headers 20.03

A sid user ought to be able to read these errors and figure out how to
deal with the situation.

The FIRST thing you should do is file a bug report, so that the bug can
be fixed in Debian.  Sid users should also be extremely familiar with
filing bug reports.  That's why you're running sid in the first place,
y'know?  So you can help Debian fix bugs.

Second, since the offending file is in an OLDER version of the
codeblocks-headers package, one which will presumably be updated with
a sid version, it should be obvious which package you want to remove,
temporarily.

Re: removing file??

[Curt Howland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


> dpkg: error processing archive 
> /var/cache/apt/archives/codeblocks-dev_20.03-3.1+
> b1_amd64.deb (--unpack):
>   trying to overwrite '/usr/include/codeblocks/Alignment.h', which 
is 
> also in pac
> kage codeblocks-headers 20.03
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>   /var/cache/apt/archives/codeblocks-dev_20.03-3.1+b1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

This can occur when you have upgraded a Debian system from one major 
version to another "in place", that is, without wiping and 
reinstalling.

Once you've gotten it to the point where this is the only error left, 
you can fix it by using a sledgehammer:

# 
dpkg -i --force-overwrite 
/var/cache/apt/archives/codeblocks-dev_20.03-3.1+b1_amd64.deb

What this does is tell the Debian package installer to do the 
overwrite. When dpkg is run as an "automatic" process it won't do it 
because such a conflict can cause serious problems if it occurs 
within a Debian version, but not _between_ Debian versions.

Or when I was running Sid for several years.

Then run your usual package manager process again to finish anything 
this error was preventing.

In my experience this kind of thing has only happened _between_ Debian 
major versions, and as such forcing the overwrite has not caused any 
problems that I could discern.

That it happens so rarely and only in such extreme circumstances is a 
testament to the quality of the Debian package maintainers and their 
attention to detail.

Curt-

- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCY246EwAKCRC2T1fo1pHh
qVn2AQDV/gJz0f19Uw+TfMOWPQWwxuqiVYh7frnnWnCSvBPs4gEAy4o6E0/K7DAf
QUlWBoo5DPui+tlBeeIL0uLFqNj6lcQ=
=abMp
-END PGP SIGNATURE-

network raid (Re: deduplicating file systems: VDO with Debian?)

[hede]

Am 10.11.2022 14:40, schrieb Curt:

(or maybe a RAID array is
conceivable over a network and a distance?).


Not only conceivable, but indeed practicable: Linbit DRBD

Re: deduplicating file systems: VDO with Debian?

[rhkramer]

On Thursday, November 10, 2022 09:06:39 AM Dan Ritter wrote:
> If you need a filesystem that is larger than a single disk (that you can
> afford, or that exists), RAID is the name for the general approach to
> solving that.

PIcking a nit, I would say: "RAID is the name for *a* general approach to
solving that." (LVM is another.)

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma included at no 
charge.)  If you change topics, change the Subject: line. 

Writing is often meant for others to read and understand (legal agreements 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace and minimal use of (obscure?) jargon, abbreviations, 
acronyms, and references.

If someone else has already responded to a question, decide whether any 
response you add will be helpful or not ...

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[tomas]

On Fri, Nov 11, 2022 at 09:12:36AM +0100, hw wrote:
> Backblaze does all kinds of things.

whatever.

> > The gist, for disks playing similar roles (they don't use yet SSDs for bulk
> > storage, because of the costs): 2/1518 failures for SSDs, 44/1669 for HDDs.
> > 
> > I'll leave the maths as an exercise to the reader.
> 
> Numbers never show you the real picture, especially not statistical ones.

Your gut feeling might be more relevant for you. But it's not for me,
so that's why I'll bow out of this thread :-)

>   You
> even say it yourself that the different types of disks were used for different
> purposes.  That makes your numbers meaningless.

Please, re-read what I wrote (you even quoted it above). It's nearly the
opposite of what you say here. I said "similar roles". I won't read the
blog entry for you aloud here.

> Out of cruiosity, what do these numbers look like in something like survivours
> per TB?  Those numbers will probably show a very different picture, won't 
> they.

DidI say similar roles? The devices compared are doing the same job, So TB
per unit time are, for all we know, comparable.

> And when even Backblaze doesn't use SSDs for backup storage because they're
> expensive, then why would you suggest or assume that anyone do or does that?

There again. Please read what others write before paraphrasing them
wrongly. I never said you should use SSDs for bulk data storage. They
are too expensive for that. That's something you, backblaze and me
all agreed from the start. Why on earth do you bring that up here, then?

I just contested that their failure rate is higher than that of HDDs.
This is something which was true in early days, but nowadays it seems
to be just a prejudice.

I'm out of this thread.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: else or Debian (Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?))

[DdB]

Am 11.11.2022 um 07:36 schrieb hw:
> That's on https://docs.freebsd.org/en/books/handbook/zfs/
> 
> I don't remember where I read about 8, could have been some documentation 
> about
> FreeNAS.

Well, OTOH there do exist some considerations, which may have lead to
that number sticking somewhere, but i have seen people with MUCH larger
pools.

In order to avoid wasting too much space, there was a "formula" to
calculate optimum pool size:
First take an amount of disks that is a result of 2^^n (like
2/4/8/16/...) and then add the number of disks you need for redundancy
(raidz = 1, raidz2 = 2, raidz3 = 3). That would give nice spots like 4+2
= 6 (identical) disks for raidz2, or 11 for raidz3. Those numbers are
sweet spots for the size of vdevs, otherwise, more space gets waisted on
the drives. But that is only ONE consideration. My motherboard has 8
connectors for SATA, + 2 for NVME, which limited my options more than
anything.
And after long considerations, i opted for 4 mirrored vdevs, giving even
more space to redundancy, but gaining read speed.

Re: deduplicating file systems: VDO with Debian?

[hw]

On Thu, 2022-11-10 at 13:40 +, Curt wrote:
> On 2022-11-08, The Wanderer  wrote:
> > 
> > That more general sense of "backup" as in "something that you can fall
> > back on" is no less legitimate than the technical sense given above, and
> > it always rubs me the wrong way to see the unconditional "RAID is not a
> > backup" trotted out blindly as if that technical sense were the only one
> > that could possibly be considered applicable, and without any
> > acknowledgment of the limited sense of "backup" which is being used in
> > that statement.
> > 
> 
> Maybe it's a question of intent more than anything else. I thought RAID
> was intended for a server scenario where if a disk fails, you're down
> time is virtually null, whereas as a backup is intended to prevent data
> loss. RAID isn't ideal for the latter because it doesn't ship the saved
> data off-site from the original data (or maybe a RAID array is
> conceivable over a network and a distance?).
> 
> Of course, I wouldn't know one way or another, but the complexity (and
> substantial verbosity) of this thread seem to indicate that that all
> these concepts cannot be expressed clearly and succinctly, from which I
> draw my own conclusions.
> 

But the performance is great ;)

Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?)

[hw]

On Thu, 2022-11-10 at 21:14 -0800, David Christensen wrote:
> On 11/10/22 07:44, hw wrote:
> > On Wed, 2022-11-09 at 21:36 -0800, David Christensen wrote:
> > > On 11/9/22 00:24, hw wrote:
> > >   > On Tue, 2022-11-08 at 17:30 -0800, David Christensen wrote:
> 
> [...]
>
> > 
> Taking snapshots is fast and easy.  The challenge is deciding when to 
> destroy them.

That seems like an easy decision, just keep as many as you can and destroy the
ones you can't keep.

> [...]
> > > Without deduplication or compression, my backup set and 78 snapshots
> > > would require 3.5 TiB of storage.  With deduplication and compression,
> > > they require 86 GiB of storage.
> > 
> > Wow that's quite a difference!  What makes this difference, the compression
> > or
> > the deduplication? 
> 
> 
> Deduplication.

Hmm, that means that deduplication shrinks your data down to about 1/40 of it's
size.  That's an awesome rate.

> > When you have snapshots, you would store only the
> > differences from one snapshot to the next, 
> > and that would mean that there aren't
> > so many duplicates that could be deduplicated.
> 
> 
> I do not know -- I have not crawled the ZFS code; I just use it.

Well, it's like a miracle :)

> > > Users can recover their own files without needing help from a system
> > > administrator.
> > 
> > You have users who know how to get files out of snapshots?
> 
> 
> Not really; but the feature is there.

That means you're still the one to get the files.

> [...]
> > 
> > 
> > > What were the makes and models of the 6 disks?  Of the SSD's?  If you
> > > have a 'zpool status' console session from then, please post it.
> > 
> > They were (and still are) 6x4TB WD Red (though one or two have failed over
> > time)
> > and two Samsung 850 PRO, IIRC.  I don't have an old session anymore.
> > 
> > These WD Red are slow to begin with.  IIRC, both SDDs failed and I removed
> > them.
> > 
> > The other instance didn't use SSDs but 6x2TB HGST Ultrastar.  Those aren't
> > exactly slow but ZFS is slow.
> 
> 
> Those HDD's should be fine with ZFS; but those SSD's are desktop drives, 
> not cache devices.  That said, I am making the same mistake with Intel 
> SSD 520 Series.  I have considered switching to one Intel Optane Memory 
> Series and a PCIe 4x adapter card in each server.

Isn't that very expensinve and wears out just as well?  Wouldn't it be better to
have the cache in RAM?


> Please run and post the relevant command for LVM, btrfs, whatever.

Well, what would that tell you?

> [...]
> > 
> > > What is the make and model of your controller cards?
> > 
> > They're HP smart array P410.  FreeBSD doesn't seem to support those.
> 
> 
> I use the LSI 9207-8i with "IT Mode" firmware (e.g. host bus adapter, 
> not RAID):

Well, I couldn't get those when I wanted them.  Since I didn't plan on using
ZFS, the P410s have to do.

> [...]
> > ... the data to back up is mostly (or even all) on btrfs. ... copy the
> > files over with rsync.  ...
> > the data comes from different machines and all backs up to one volume.
> 
> 
> I suggest creating a ZFS pool with a mirror vdev of two HDD's.

That would be way too small.

>   If you 
> can get past your dislike of SSD's,

I don't dislike them.  I'm using them where they give me advantages, and I don't
use them where they would give me disadvantages.

>  add a mirror of two SSD's as a 
> dedicated dedup vdev.  (These will not see the hard usage that cache 
> devices get.)

I think I have 2x80GB SSDs that are currently not in use.

>   Create a filesystem 'backup'.  Create child filesystems, 
> one for each host.  Create grandchild filesystems, one for the root 
> filesystem on each host.

Huh?  What's with these relationships?

>   Set up daily rsync backups of the root 
> filesystems on the various hosts to the ZFS grandchild filesystems.  Set 
> up zfs-auto-snapshot to take daily snapshots of everything, and retain 
> 10 snapshots.  Then watch what happens.

What do you expect to happen?  I'm thinking about changing my backup sever ... 
In any case, I need to do more homework first.

Re: definiing deduplication

[Thomas Schmitt]

Hi,

i wrote:
> > Data of different files or at different places in the same file
> > may have relations which may become inconsistent during change operations
> > until the overall change is complete.

Stefan Monnier wrote:
> Arguably this can be considered as a bug in the application (because
> a failure in the middle could thus result in an inconsistent state).

A backup programmer or operator does not necessarily have influence on
such applications.


> if you don't use snapshots, [...] the bug is in the backup
> process itself.

The backuper is not to blame if the backupee filesystem cannot make
snapshots, and anyways snapshots don't completely solve the consistency
problem of backups.

That's another reason why i propose to divide the backupee into several
subsets which separate agile parts from lazy parts.
The backup of agile data possibly needs special precautions like shutting
down or pausing particular applications.

Having multiple backups of the same backupee reduces the risk to have
no consistent copy when the backup needs to be restored.


Have a nice day :)

Thomas

Re: ZFS performance

[hede]

On 10.11.2022 16:44, hw wrote:


I accidentally trash files on occasion.  Being able to restore them
quickly and easily with a cp(1), scp(1), etc., is a killer feature.


indeed


I'd say the same and I do use a file based backup solution and love 
having cp, scp, etc.


Still, having a tool which could do that out of a block based backup 
solution makes no difference here. And backup solutions typically do 
offer those.


I guess btrfs could, in theory, make something like boot environments 
possible,
but you can't even really boot from btrfs because it'll fail to boot as 
soon as
the boot volume is degraded, like when a disc has failed, and then 
you're
screwed because you can't log in through ssh to fix anything but have 
to
actually go to the machine to get it back up.  That's a non-option and 
you have

to use something else than btrfs to boot from.


First, is this still the case? I do use btrfs for the root disk, had 
such a failure and do not remember to had any issues like that. 
(disclaimer: booting via EFI and systemd boot stub and secureboot signed 
kernel and initrd on the EFI partition - no grub etc.)


Second, there's still dropbear inside the initrd. For Debian it's simple 
to use: install dropbear-initramfs.
I use it because I do use full drive encryption on a headless system. If 
it fails to decrypt and boot via TPM (which is a nice feature for fully 
encrypted headless systems!) then I have to manually boot the system via 
SSH. (happened in the "learning phase")


regards
hede

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

[hw]

On Fri, 2022-11-11 at 08:01 +0100, to...@tuxteam.de wrote:
> On Fri, Nov 11, 2022 at 07:15:07AM +0100, hw wrote:
> > On Thu, 2022-11-10 at 23:05 -0500, Michael Stone wrote:
> 
> [...]
> 
> > Why would anyone use SSDs for backups?  They're way too expensive for that.
> 
> Possibly.
> 
> > So far, the failure rate with SSDs has been not any better than the failure
> > rate
> > of hard disks.  Considering that SSDs are supposed to fail less, the
> > experience
> > with them is pretty bad.
> 
> You keep pulling things out of whatever (thin air, it seems).

That's more like what you're doing.  In my case, it's my own experience.

>  Here's a report
> by folks who do lots of HDDs and SDDs:
> 
>   https://www.backblaze.com/blog/backblaze-hard-drive-stats-q1-2021/

Backblaze does all kinds of things.

> The gist, for disks playing similar roles (they don't use yet SSDs for bulk
> storage, because of the costs): 2/1518 failures for SSDs, 44/1669 for HDDs.
> 
> I'll leave the maths as an exercise to the reader.

Numbers never show you the real picture, especially not statistical ones.  You
even say it yourself that the different types of disks were used for different
purposes.  That makes your numbers meaningless.

Out of cruiosity, what do these numbers look like in something like survivours
per TB?  Those numbers will probably show a very different picture, won't they.

And when even Backblaze doesn't use SSDs for backup storage because they're
expensive, then why would you suggest or assume that anyone do or does that?

Re: else or Debian (Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?))

[hw]

On Thu, 2022-11-10 at 23:12 -0500, Michael Stone wrote:
> On Thu, Nov 10, 2022 at 08:32:36PM -0500, Dan Ritter wrote:
> > * RAID 5 and 6 restoration incurs additional stress on the other
> >  disks in the RAID which makes it more likely that one of them
> >  will fail.
> 
> I believe that's mostly apocryphal; I haven't seen science backing that 
> up, and it hasn't been my experience either.

Maybe it's a myth that comes about when someone rebuilds a RAID and yet another
disk in it fails (because they're all same age and have been running under same
conditions).  It's easy to jump to conclusions and easy jumps is what people
like.

OTOH, it's not too unplausible that a disk might fail just when it's working
particularly hard.  If it hadn't been working so hard, maybe it would have
failed later because it had more time to wear out or when the ambient
temperatures are higher in the summer.  So who knows?

> >  The advantage of RAID 6 is that it can then recover
> >  from that...
> 
> The advantage to RAID 6 is that it can tolerate a double disk failure. 
> With RAID 1 you need 3x your effective capacity to achieve that and even 
> though storage has gotten cheaper, it hasn't gotten that cheap. (e.g., 
> an 8 disk RAID 6 has the same fault tolerance as an 18 disk RAID 1 of 
> equivalent capacity, ignoring pointless quibbling over probabilities.)

so with RAID6, 3x8 is 18 instead of 24

With 18 disks more can go wrong than with 8.  That's all kinda confusing.