On Thu, 4 Jun 2020 at 00:56:59, JJ wrote:
On Wed, 3 Jun 2020 11:53:58 +0100, J. P. Gilliver (John) wrote:
On Wed, 3 Jun 2020 at 02:51:28, Andy wrote:
[]
I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy

I occasionally see such claims (can't comment on which FS).

I fail to understand how _any_ file system can not _require_
defragmenting - unless it does not allow fragmenting in the first place
(like the BBC "DFS"), which then needs "compacting" from time to time.
(I also cannot see how such a FS can _handle_ a situation where two or
more files are being written at once, e. g. a logging and a recording.)

I'm willing to have it explained to me, though.

It's an exaggeration of Ext#, IMO.

Thanks for the explanations. Yes, I agree the claims are exaggerated.

Ext# file systems can actually be fragmented. What makes them seem to never
need a defragmenter is mainly because of how Ext# driver/handler manages the
file systems. Mainly it's because of these two things.

1. Ext# driver/handler always try to allocate non fragmented clusters for a
newly created file.

Fine if you know how big the file is going to be when you open it.

2. Ext# driver/handler has an automatic file relocator feature (not to be
confused with file defragmenter). If file appending process would end up
fragmenting the file (i.e. because the following cluster is already used),
the file will be relocated to somewhere else where the following clusters is
large enough to fit the appended data, then the appended data is written.
So, the file never get into a fragmented state.

So there'll be a sudden pause while the file-so-far is suddenly moved.

In #1, when there's enough disk free space but not enough free space
fragments, e.g. new file size is 80MB, disk free space is 100MB in two free
space fragments: 60MB and 40MB; #2 will kick in to extend a free space
fragment to large enough size to hold the new file. In this case, #2 does
not defragment files, but relocate files. However, it _does_ defragment the
free space. However, linux users seem to consider the term "defragment" is
only applicable for files.

So it moves the file(s) that are between the two free space blocks.
Again, sudden pause while it does so.

That being said, _all_ (built in) Windows file system drivers are still
worse than Ext# in terms of fragmentation - where sometimes (if not, in most
cases), _deliberately_ fragment newly created files even though there is
enough free space fragment to hold the new files without fragmentation, and
even though no other process (not even the system) is using the disk to
write something.

If I understand you rightly, "deliberately" is overstating the case a
teeny bit: not deliberately fragmenting, just not moving to the first
huge gap when writing starts. Again, not practical for
continuously-growing files, like a recording. Or log, though those _are_
usually smaller.

I _can_ see the advantages for certain kinds of use.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

If you think privacy is unimportant for you because you have nothing to hide,
you might as well say free speech is unimportant for you because you have
nothing useful to say - Garas Paras @GarasParas on Twitter, 2020-5-5