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

Groups > comp.os.linux.advocacy > #680963 > unrolled thread

Windows 11 for Workstations vs. Linux Mint

Back to article view | Back to comp.os.linux.advocacy

Contents

  Windows 11 for Workstations vs. Linux Mint vallor <vallor@cultnix.org> - 2024-12-21 05:36 +0000
    Re: Windows 11 for Workstations vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-21 07:07 +0000
      Re: Windows 11 for Workstations vs. Linux Mint Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-12-21 07:54 -0500
        Re: Windows 11 for Workstations vs. Linux Mint CrudeSausage <crude@sausa.ge> - 2024-12-21 08:45 -0500
      Re: Windows 11 for Workstations vs. Linux Mint vallor <vallor@cultnix.org> - 2024-12-21 23:27 +0000
    Re: Windows 11 for Workstations vs. Linux Mint -hh <recscuba_google@huntzinger.com> - 2024-12-21 09:25 -0500
      Re: Windows 11 for Workstations vs. Linux Mint Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-21 21:05 +0000
      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

#680963 — Windows 11 for Workstations vs. Linux Mint

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.)

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.12.6 Release: Mint 21.3 Mem: 258G
   "I keep my .BAT files in E:\BELFRY"

[toc] | [next] | [standalone]

#680968

On 21 Dec 2024 05:36:50 GMT, vallor wrote:

> A major reason I went with the "Workstation"
> Windows was to evaluate ReFS, and so far, I'm not impressed.

Microsoft still have your money though, don’t they?

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

#680986

Lawrence D'Oliveiro wrote this post while blinking in Morse code:

> On 21 Dec 2024 05:36:50 GMT, vallor wrote:
>
>> A major reason I went with the "Workstation"
>> Windows was to evaluate ReFS, and so far, I'm not impressed.
>
> Microsoft still have your money though, don’t they?

The first thing I did when I booted Win 11 on the mini PC was use Disk Manager
to shrink the NTFS partition.  Surprisingly, no pain, no need to defragment
first.

-- 
I may be getting older, but I refuse to grow up!

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

#680991

Le 2024-12-21 à 07:54, Chris Ahlstrom a écrit :
> Lawrence D'Oliveiro wrote this post while blinking in Morse code:
> 
>> On 21 Dec 2024 05:36:50 GMT, vallor wrote:
>>
>>> A major reason I went with the "Workstation"
>>> Windows was to evaluate ReFS, and so far, I'm not impressed.
>>
>> Microsoft still have your money though, don’t they?
> 
> The first thing I did when I booted Win 11 on the mini PC was use Disk Manager
> to shrink the NTFS partition.  Surprisingly, no pain, no need to defragment
> first.

What we've learned from you over the years is that you have a high 
threshold for pain. That's why the neighbourhood negroes nicknamed you 
Titanium Sphincter.

-- 
CrudeSausage

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

#681029

On Sat, 21 Dec 2024 07:07:35 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <vk5pfn$3u2dr$1@dont-email.me>:

> On 21 Dec 2024 05:36:50 GMT, vallor wrote:
> 
>> A major reason I went with the "Workstation"
>> Windows was to evaluate ReFS, and so far, I'm not impressed.
> 
> Microsoft still have your money though, don’t they?

In my case, yes.

But one can install it and not activate it for evaluation -- you
just won't be able to "personalize" it.

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.12.6 Release: Mint 21.3 Mem: 258G
   "Where does the fire go when the fire goes out?"

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

#680995

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?

-hh

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

#681010

On Sat, 21 Dec 2024 09:25:29 -0500, -hh wrote:

> So where do you think the problem resides?

The problem resides in the fact that the resizing code has to be specific 
to the filesystem format. This code exists for common Linux filesystems 
and for NTFS, but not ReFS.

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

#681021

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] | [prev] | [next] | [standalone]

#681039

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]

#681042

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]

#681051

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]

#681088

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]

#681099

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 | comp.os.linux.advocacy

csiph-web