Path: ...!Xl.tags.giganews.com!local-2.nntp.ord.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 23 Jan 2025 02:29:57 +0000
Subject: Re: News : ARM Trying to Buy AmperComputing
Newsgroups: comp.os.linux.misc
References: <_hycnQxlN5kAphr6nZ2dnZfqn_SdnZ2d@earthlink.com>
 <198f4f8c-a0d0-7caf-b67e-1f61fee9de41@example.net>
 <UcicndjNUaEg0hH6nZ2dnZfqnPSdnZ2d@earthlink.com>
 <35e42921-5781-8728-236f-afad1d3b56b1@example.net>
 <vSydnd3xKfdNFhD6nZ2dnZfqn_udnZ2d@earthlink.com>
 <7258fd01-44f7-850d-3f69-54b93489f64d@example.net>
 <vml7e7$31s95$1@dont-email.me>
 <69ce04cf-80a7-7170-675f-4165ffedc92b@example.net>
 <RtudnVi93qkPcBP6nZ2dnZfqnPudnZ2d@earthlink.com>
 <4985abd5-ec8c-44da-0105-0778434959c0@example.net>
 <vmou5k$bc8h$1@dont-email.me>
 <d9idnf_tAICqpA36nZ2dnZfqnPqdnZ2d@earthlink.com>
 <27da50fc-f7e3-1462-2bf0-8e234043a319@example.net>
From: "186282@ud0s4.net" <186283@ud0s4.net>
Organization: wokiesux
Date: Wed, 22 Jan 2025 21:29:55 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <27da50fc-f7e3-1462-2bf0-8e234043a319@example.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <PoCdnawcq8s4NAz6nZ2dnZfqn_ednZ2d@earthlink.com>
Lines: 152
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 99.101.150.97
X-Trace: sv3-4iWj9k/XDQgQzknQaYCnEcbUnqk9kZzJMdibbob2RQhQJ9HfLl5GxuI+FqMq/Fb1bxiXaaYqHoaAJfg!/jjJcadzmWB1MV6gpXJACTnFZIP873qqotn0AznWaDx6fkGmfTzYKwiaoViaHci3N+HolzWkhZuO!fCdxDLCvZpZmBWLQvNEv
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 8160

On 1/22/25 4:32 AM, D wrote:
> 
> 
> On Tue, 21 Jan 2025, 186282@ud0s4.net wrote:
> 
>> On 1/21/25 2:56 PM, Rich wrote:
>>> D <nospam@example.net> wrote:
>>>> [-- text/plain, encoding 8bit, charset: utf-8, 94 lines --]
>>>>
>>>>
>>>>
>>>> On Mon, 20 Jan 2025, 186282@ud0s4.net wrote:
>>>>
>>>>> On 1/20/25 3:53 PM, D wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, 20 Jan 2025, The Natural Philosopher wrote:
>>>>>>
>>>>>>> On 20/01/2025 09:30, D wrote:
>>>>>>>>>
>>>>>>>>>   The Pi hat or OMV ?
>>>>>>>>
>>>>>>>> The pi, with directly connected spinning disks. Does the hat 
>>>>>>>> have its own
>>>>>>>> extra power supply?
>>>>>>>
>>>>>>> I've managed to get a P4 I think to run one spinning rust disk 
>>>>>>> without
>>>>>>> extra power.
>>>>>>> Strictly it depends on the disk.
>>>>>>> The pi hat for 5 drives has an external 60W PSU
>>>>>>
>>>>>> Ahh, if it has an external PSU then there is no problem. Ideally, 
>>>>>> if the pi
>>>>>> hat for 5 drives is intended to accomodate 5 spinning drives, it 
>>>>>> would be
>>>>>> nice if it did so at full speeds.
>>>>>
>>>>>
>>>>>   One review said the WRITEs were a little pokey,
>>>>>   but not TOO bad. READs were apparently snappy.
>>>>>
>>>>>   This is OK ... most stuff on HDDs is "write once /
>>>>>   read more often".
>>>>
>>>> Hmm, do you have a link? What does "a little pokey" mean in terms of
>>>> writes? If it is only performance and latency related, then it is ok,
>>>> since the software will take care of a lot of that for me.
>>>
>>> The nymshift troll was likely referring to two possibilities:
>>>
>>> 1) SMR mechanical drives
>>> 2) SSD's
>>>
>>> In both cases, writes have to be done in what amounnts to a "two step
>>> process".
>>>
>>> For SMR drives, because the magnetic tracks physically overlap, writes
>>> get queued to a non SMR area, and then get "moved" to the actual disk
>>> sectors as a bigger batch to maintain the proper "overlap" of the
>>> magnetic tracks.
>>>
>>> For SSD's, writes occur to an "erased" flash block (typically much
>>> larger than a "disk sector" size used by the host) and given enough
>>> writes over a short enough timeframe the SSD controller can run out of
>>> "pre-erased" blocks to use, and when that happens write speed slows
>>> down to the rate that can be done when a "block erase" has to occur
>>> before the actual writes can hit the media.  Note that this "block
>>> erase" can also invove moving any partially used data sectors out of
>>> the block into another block, creating a "write amplification"
>>> situation as well.
>>
>>
>>  Disks - magnetic or SSD - are kinda messy. Of course
>>  their mission is kinda messy - deal with odd-sized
>>  blobs of data, try to jam it in somewhere, maybe have
>>  to move pre-existing around, try not to create TOO
>>  many 'gaps', for years and years.
>>
>>  SSDs are quicker regardless and use less power, but
>>  that doesn't mean they're just a petabyte of empty
>>  space, STUFF has to happen. SSDs trend smaller than
>>  HDDs too and are more $$$ per terabyte. Yer basic
>>  WD/Seagte magnetic laptop drives are a pretty good
>>  deal IF you can handle the power req.
> 
> This is the truth!
> 
>>  Made a "different building" aux backup unit using
>>  a Pi-3 and 2.5" USB mag drive. The idea was to
>>  keep the Most Important Stuff in a separate
>>  building, separate leg of the power system. Used
>>  wi-fi ... but had all day to do its thing. This
>>  was protection against lighting/surges/fires
>>  and the dreaded Giant Mug Of Coffee that might
>>  afflict the main NAS. Cheap, worked great, a
>>  Python pgm to do the backups (DO confirm yer
>>  USB and NAS are both mounted). The USB drive
>>  was powered by the Pi, not an external wart.
>>  The drive and Pi were taped together and the
>>  whole mess was velcroed to the underside of a
>>  shelf out in a shop building.
> 
> Good stuff! I replicate between two countries for added resilience. Both 
> rsync and restic work great backing up to a tor hidden service. To speed 
> things up, the first backup can be done locally, and after that, only 
> deltas are sent from around the world.

   That's how we do it.

> So far restic is still good. I wonder what its weaknesses are? Would be 
> a shame to drop my trusted old rsync script + hardlinks in favour of 
> restic only to discover some hidden bug. On the other hand it seems as 
> if 1000s of people all over the world are using it and are happy with 
> it, so maybe it is mature enough.

   I've generally used rsync, though rarely as client/server.
   It's quick and (for better or worse) has lots of options.
   DID find a serious prob once though using the --delete op
   however ... the source got unmounted and rsync interpreted
   that as an empty folder and, as told, cleaned out all
   those 'obsolete' backups. That took about 30 hours to
   rebuild ....

   I've also writ Python and Pascal pgms that do about the
   same thing as basic rsync. Get the source folder tree,
   copy to wherever after translating to folder tree to
   match the destination drive/folder. The good bit there
   is that you can CHECK the mount status of src/dest
   between every file copy, just a quick peek at /proc/mounts.
   You can also like ZIP and or encrypt the backups, using
   some standard naming scheme, file-by-file during the backup.

   Often you need just a few files from backup, ones somebody
   oopsied, so huge zip archives can be a negative. OpenSSL
   works fast for encryption and the Winders version has
   almost exactly the same params. GPG is not so good in
   the file-by-file thing because it has a relatively
   long start-up time.

   Have never used restic, I'll have to give it a look.

   Another way to back up is to 'fork' every file write
   to another, maybe even remote, drive. SoftRAID seems
   to know just what's being written but I've never
   figured out exactly how that works. The idea would
   be to feed the full file path/name of what's just
   been writ/modified into a (de-duplicated) list for
   some daemon or whatever to dupe to yer destination -
   local or cloud. This would be very quick and not bother
   the other gazillion unchanged files.