Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.os.windows-11 > #15579 > unrolled thread

Re: Windows 11 for Workstations vs. Linux Mint

Back to article view | Back to alt.comp.os.windows-11

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Windows 11 for Workstations vs. Linux Mint vallor <vallor@cultnix.org> - 2024-12-21 22:40 +0000
    Re: Windows 11 for Workstations vs. Linux Mint Paul <nospam@needed.invalid> - 2024-12-21 20:56 -0500
      Re: Windows 11 for Workstations vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-22 03:46 +0000
        Re: Windows 11 for Workstations vs. Linux Mint Paul <nospam@needed.invalid> - 2024-12-22 04:08 -0500
          Re: Windows 11 for Workstations vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-22 20:32 +0000
            Re: Windows 11 for Workstations vs. Linux Mint Paul <nospam@needed.invalid> - 2024-12-22 17:42 -0500

#15579 — Re: Windows 11 for Workstations vs. Linux Mint

On Sat, 21 Dec 2024 09:25:29 -0500, -hh <recscuba_google@huntzinger.com>
wrote in <vk6j4q$2e70$2@dont-email.me>:

> On 12/21/24 12:36 AM, vallor wrote:
>> So I wanted to see what all the shouting was about.  Installed Windows
>> 11 for Workstations in a virt, and gave the virt access to /dev/sda,
>> which is a 1TB iSCSI instance on my machine.
>> 
>> Created a ReFS partition on it.  After fiddling around with it a while,
>> I tried to resize the filesystem.  Disk Manager said "the volume cannot
>> be shrunk because the file system does not support it".
>> 
>> ext4 filesystems can be resized, and are suitable for workstation
>> applications.  A major reason I went with the "Workstation"
>> Windows was to evaluate ReFS, and so far, I'm not impressed.
>> 
>> RESIZE2FS(8)        System Manager's Manual        RESIZE2FS(8)
>> 
>> NAME
>>         resize2fs - ext2/ext3/ext4 file system resizer
>> 
>> SYNOPSIS
>>         resize2fs  [  -fFpPMbs  ]  [ -d debug-flags ] [ -S RAID- stride
>>         ] [ -z undo_file ] device [ size ]
>> 
>> DESCRIPTION
>>         The resize2fs program will resize ext2,  ext3,  or  ext4 file 
>>         systems.   It  can be used to enlarge or shrink an unmounted
>>         file system located on device.   If  the  file system  is
>>         mounted, it can be used to expand the size of the mounted file
>>         system, assuming  the  kernel  and  the file  system  supports 
>>         on-line resizing.  (Modern Linux 2.6 kernels will support
>>         on-line resize for file systems mounted  using ext3 and ext4;
>>         ext3 file systems will re‐
>>         quire the use of file systems with the resize_inode fea‐
>>         ture enabled.)
>> 
>> 
> So where do you think the problem resides?  I'd suspect the iSCSI
> instance ... did you try testing it on a more traditional disk target?

The "problem" is that ReFS doesn't support resizing.  NTFS does -- but
ReFS is their "workstation" filesystem, which you can't get unless you
use Windows for Workstations.

They'd be better off supporting ext4.

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.12.6 Release: Mint 21.3 Mem: 258G
   "Cogito ergo spud I think therefore I yam."

[toc] | [next] | [standalone]

#15589

On Sat, 12/21/2024 5:40 PM, vallor wrote:
> On Sat, 21 Dec 2024 09:25:29 -0500, -hh <recscuba_google@huntzinger.com>
> wrote in <vk6j4q$2e70$2@dont-email.me>:
> 
>> On 12/21/24 12:36 AM, vallor wrote:
>>> So I wanted to see what all the shouting was about.  Installed Windows
>>> 11 for Workstations in a virt, and gave the virt access to /dev/sda,
>>> which is a 1TB iSCSI instance on my machine.
>>>
>>> Created a ReFS partition on it.  After fiddling around with it a while,
>>> I tried to resize the filesystem.  Disk Manager said "the volume cannot
>>> be shrunk because the file system does not support it".
>>>
>>> ext4 filesystems can be resized, and are suitable for workstation
>>> applications.  A major reason I went with the "Workstation"
>>> Windows was to evaluate ReFS, and so far, I'm not impressed.
>>>
>>> RESIZE2FS(8)        System Manager's Manual        RESIZE2FS(8)
>>>
>>> NAME
>>>         resize2fs - ext2/ext3/ext4 file system resizer
>>>
>>> SYNOPSIS
>>>         resize2fs  [  -fFpPMbs  ]  [ -d debug-flags ] [ -S RAID- stride
>>>         ] [ -z undo_file ] device [ size ]
>>>
>>> DESCRIPTION
>>>         The resize2fs program will resize ext2,  ext3,  or  ext4 file 
>>>         systems.   It  can be used to enlarge or shrink an unmounted
>>>         file system located on device.   If  the  file system  is
>>>         mounted, it can be used to expand the size of the mounted file
>>>         system, assuming  the  kernel  and  the file  system  supports 
>>>         on-line resizing.  (Modern Linux 2.6 kernels will support
>>>         on-line resize for file systems mounted  using ext3 and ext4;
>>>         ext3 file systems will re‐
>>>         quire the use of file systems with the resize_inode fea‐
>>>         ture enabled.)
>>>
>>>
>> So where do you think the problem resides?  I'd suspect the iSCSI
>> instance ... did you try testing it on a more traditional disk target?
> 
> The "problem" is that ReFS doesn't support resizing.  NTFS does -- but
> ReFS is their "workstation" filesystem, which you can't get unless you
> use Windows for Workstations.
> 
> They'd be better off supporting ext4.
> 

You can actually make ReFS on *any* version of Windows 11.
Like, even the lowly Home. You turn on Developer Mode,
reboot, and in the Advanced Storage Settings is an option
to create a Dev Drive. I didn't have room on the Home machine,
and used the Win11 Pro machine across the way for a PhotoOP.

   [Picture]

    https://i.postimg.cc/zv8QJTFL/Re-FS-W11-DEV-DRIVE.gif

what was really funny, is Macrium Reflect, pretended there was
no file system on there at all. Leaving no doubt in your mind
about whether it gets backed up or not. I thought of that as
being "almost special", like riding on the short bus.

But, a Delete Volume and it's gone again. What's not to like.

There is a rule about Windows:

    "If it don't got tools, we don't use it"

This includes things like .vhdx , which is perilously
close to an orphan. One of my requirements for VM containers,
is that they can be transmuted into some other container type.
This is one of the reasons that Hyper-V is not installed on any
machine here. I'm sure the software would work and would be nice,
but the containers suck. 7ZIP tool, by Igor Pavlov, it opens
.vhd files and allows you to burrow into the file system in there.
It doesn't work on .vhdx , and that alone is enough to doom
.vhdx to the dustbin. ReFS still has a similar status.
And as long as tools do things such as "pretending there is
no file system", I think you can see how excited I am about
this.

NTFS has journaling, and normally (most always), survives
power cuts. It cleans up on reboot, and away we go. The Registry
used to corrupt years ago. The Registry now has its own journal.
This means, we no longer get Registry corruption. NTFS then,
is now just about perfect, without any help at all from ReFS.
ReFS is like a museum item, by comparison. As long as it
is not mainstream, what good is it ??? Yeah, I know, technically
it has amazing specs. Great.

   Paul

[toc] | [prev] | [next] | [standalone]

#15592

On Sat, 21 Dec 2024 20:56:27 -0500, Paul wrote:

> NTFS then, is now just about perfect ...

Still does a poor job of handling lots of small files, though.

[toc] | [prev] | [next] | [standalone]

#15595

On Sat, 12/21/2024 10:46 PM, Lawrence D'Oliveiro wrote:
> On Sat, 21 Dec 2024 20:56:27 -0500, Paul wrote:
> 
>> NTFS then, is now just about perfect ...
> 
> Still does a poor job of handling lots of small files, though.
> 

First and foremost, we want file systems that
don't lose any of our goods. The file systems we
have now, are more robust than they used to be,
and this is a start. The file system is scanned in
the background, details are not provided as to
how this works, merely that latent faults are not
an issue as they used to be.

I don't live on a diet of synthetic tests. Synthetic
tests are fun, but that's for characterization and
telling people the best way to use the file systems.

The file system is good enough for casual home user
usage. I would not bill something like NTFS as
a hyperscaler product.

I can tell you from my testing, not to put four billion
files in a single flat directory. The transfer would
never finish. Balanced trees of files work better,
and you might be able to handle 4x the files that way.
I would also not attempt to put four billion files
in a balanced tree. When the Wiki article on NTFS
says the file system has a theoretical limit of
four billion files, I doubt anyone has finished the
test of that statement. It is quite common in file systems,
to over-promise, and discover by exhaustive testing,
the limit of the file system is not actually as stated
on the tin. Apple for example, had two incidents, where
they released a TN stating a capability, and then three
months later, had to retract and rewrite a few of the
TN details to suit.

The OS has enough issues with things like File Explorer,
to discourage running a giant lemonade stand off the OS.
It's not nearly good enough for that.

The Federated Search has a recommended max size of one
million files. I have 1.2 million files on my collection,
and the federated search works OK on that. The reason
for the recommended size, is it takes a whole day to
index a file collection that big. And it slows down
the larger the collection. As you would expect with
the generation of inverted indexes.

When I do synthetic tests here, I do them on a RAM drive,
not for speed (nothing has "speed" here), that's just to
avoid shaking the disk drive to shit. The fastest way to
transfer files off a Windows disk, is at cluster level
with a backup product. I can transfer 40 million files
from one storage device to another in ten minutes, if
working at the cluster level. Then enjoy random accessing
them through the file system again, once the files are
on the new device. For performance reasons, I would never
recommend  cp -R src dest as the "right way" for every job.
Transferring 40 million files with a cp -R, that's going
to take more than a day to do. and that's why we experiment
with the odd synthetic case, to see what the best method is.

   Paul

[toc] | [prev] | [next] | [standalone]

#15609

On Sun, 22 Dec 2024 04:08:36 -0500, Paul wrote:

> I don't live on a diet of synthetic tests.

Neither do I. I have done real-world applications involving keeping 
hundreds of thousands of individual files in a single directory.

> The file system is good enough for casual home user
> usage.

I’m sure it is. So was CP/M. If a toy OS is good enough for you, then 
fine. Some of us need more than that for mission-critical purposes.

> I can tell you from my testing, not to put four billion
> files in a single flat directory. The transfer would
> never finish.

I’m sure that’s true on Windows. But on Linux, my expectation is, somebody 
has already tested it to make sure it works.

Here’s a fun thing: try putting four billion files into an NTFS directory, 
not from Windows, but from Linux. You will likely find it works a lot 
better.

[toc] | [prev] | [next] | [standalone]

#15611

On Sun, 12/22/2024 3:32 PM, Lawrence D'Oliveiro wrote:

> 
> Here’s a fun thing: try putting four billion files into an NTFS directory, 
> not from Windows, but from Linux. You will likely find it works a lot 
> better.
> 

Well, you and I, we know the NTFS driver on Linux is slower
than the one on Windows. And understandably so, when
the NTFS driver was designed by painstaking reverse
engineering, rather than having a spec in hand to aid
in writing the driver.

I once carried out a test, comparing NTFS file creation
to TMPFS file creation. At the time (a slower processor),
NTFS could CreateFile() about 4000 files a second.
TMPFS could create 186000 files a second.

But what I didn't discover at the time, is that as TMPFS
fragments, it gets slower, and it is hard to say what
the steady state for it would be, from a performance perspective.

*******

I just spun up a backup file with 64 million files in it.
It took maybe twelve minutes to restore.

If I do Properties on the restored folder, it takes *one hour*
to count the 64 million files. And this is a tree
structure, not a single flat directory.

   [Picture]

    https://i.postimg.cc/3xWsRv4d/64-million-files-writeidx4.gif

The file system could hold 64 times that many files,
but my hardware setup can't go there (not enough room).
There is a computer that could do it, but I can't
afford that (a computer that could hold four
billion files in RAM). That's the largest experiment I can do,
which does not wear any hardware at all. No hard drive
heads got slapped around 64 million times to make that.

  Paul

[toc] | [prev] | [standalone]

Back to top | Article view | alt.comp.os.windows-11

csiph-web