Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Paul <nospam@needed.invalid>
Newsgroups: comp.os.linux.advocacy,alt.comp.os.windows-10
Subject: Re: Cult of Unix
Date: Fri, 17 Jan 2025 20:53:08 -0500
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <vmf1i6$cfl1$1@dont-email.me>
References: <1VcgP.54962$XfF8.39289@fx04.iad> <vm1itg$1f1ma$3@dont-email.me>
 <vm40cl$21e8l$2@dont-email.me> <6h1bojt7kdp4d5euq0f78rtuvqpg7edc3e@4ax.com>
 <HHghP.135123$5c34.129668@fx47.iad>
 <la6bojl7t4686ll2teomlj0ig70ma8o8c8@4ax.com>
 <Q3hhP.45732$nlJ1.37298@fx41.iad>
 <ru7bojpl0j6ot182uuhhvrakcflqsadi30@4ax.com> <vm48v6$23a1f$2@dont-email.me>
 <luodsdF6geaU1@mid.individual.net> <vm755l$2lqjk$1@dont-email.me>
 <vma3u7$3cdmt$1@dont-email.me> <vmb8t8$3id01$1@dont-email.me>
 <lusp13Frb66U1@mid.individual.net> <vmbrbq$3ln7i$1@dont-email.me>
 <vmc3cq$3n232$1@dont-email.me> <vmcgfd$3osq8$2@dont-email.me>
 <luu2eeF3kf9U1@mid.individual.net> <vmcvoo$3umjn$1@dont-email.me>
 <vmeqm0$ad69$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 18 Jan 2025 02:53:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1f9033e5c9efe9dd8685b726c5f9909b";
	logging-data="409249"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18QGCs+EjLoH7p8Zqo4LtclN748L2X1KkY="
User-Agent: Ratcatcher/2.0.0.25 (Windows/20130802)
Cancel-Lock: sha1:4Hkf8Z0y+CxkiYIDJhA1z1cx0+0=
Content-Language: en-US
In-Reply-To: <vmeqm0$ad69$2@dont-email.me>
Bytes: 3733

On Fri, 1/17/2025 6:55 PM, Lawrence D'Oliveiro wrote:
> On Fri, 17 Jan 2025 02:10:16 -0500, Paul wrote:
> 
>> That's *not* how you transfer sixty million files.
> 
> And yet it worked, as per the original article. Being a file-level copy, 
> it could move the files between entirely different filesystem formats and 
> volume sizes. And do so efficiently.
> 
> Windows seems to force you into thinking in terms of sector-level copies 
> and low-level “imaging” and like that. Filesystems are supposed to 
> abstract away from all that. They do on Linux, but it seems Windows hasn’t 
> quite caught up to that idea yet.
> 

No, you just gotta use your brain. That is all.

Who in their right mind, picks the least efficient
way to do something ? The slowness of large hard drives,
demands discipline on the part of the operator, no
matter what OS they're on. Always find and execute
the efficient way.

Why do yo think I do these experiments ? I want
some measure of how bad these things are.

at some point, the effects of file system slowness,
are swamped out by the size of the files. If you
have 64 million files each 1GB in size, then
it hardly matters if an additional seek is required
to stat() the file.

*******

I haven't finished testing, but while testing Macrium again,
I noticed a new issue. These are the breadcrumbs.

     Feature_C12

     tune2fs -O ^orphan_file /dev/mydevice     # I presume this downgrades 6.x kernel EXT4 with this being enabled.
     e2fsck -f /dev/mydevice                   # By doing that, Macrium Reflect should be able to back them up again.

I got the warning about Feature_C12 and I also was not
able to burrow into the EXT4_Feature_C12 partition with
7ZIP switch army knife. So that feature is a general
problem for me, and my small set of cross-platform tools.
That is why I will need to finish testing it. Because the
Feature_C12 is going to slowly leak into my disk collection.

   Paul