Ok my time has come, you will all get the filesystem rant! The below is written as a general guide and anyone who knows better than me is invited to chime in. The reason this applies is because the DNS-323 uses EXT*.
This is going to take a while so I will spoil the end for everyone.
EXT* does fragment, no it does not need regular defragmentation. And there are filesystem tools, you just can't access them.
A file system is the logical addressing of physical partitions on a storage media.
Windows users will no doubt be familiar with FAT, VFAT, FAT32, and NTFS
Mac users will know and love HPFS and HPFS+
*nix heads however can not agree on anything at all, 2 families of file systems have reigned in as the default filesystem for most Linux distros, however a list of files systems available in Linux would include the following
EXT2, EXT3, ReiserFS, JFS, XFS, NFS, and many many more.
But what does that mean to you you ask?
First and foremost it means that we need to drop pre-conceived notions of what constitutes good filesystem management. We have to accept we are not in Kansas anymore.
What exactly is fragmentation?
When a filesystem writes a file to the disk it has the very fun duty of maintaining a method of addressing it both logically and physically. This physical addressing should be absolutely invisible to the user, the logical addressing is the file structure you are so used to. The physical addressing is however where things get tricky. Please see below.
For this example we are going to have a 20 character storage medium and 3 files of varying lengths, one is all asterisks, one is all pounds, and one is all zeros. Dashes represent free space.
We write a file to the disk consisting of 8 asterisks.
********------------
We write a file consisting of 10 pounds.
********##########--
We delete the asterisk file.
--------##########--
We add back a file of 3 asterisks.
***-----##########--
We add a file of 7 zeros, but wait it won't fit sequentially so we fragment it. We don't delete and re-write the file of 10 pounds as that would add a lot of wear and tear on the drive and take forever.
***00000##########00
As you can see now we have a system where sequential files are merely accidents after you write your first set of files equal to the capacity of the drive.
The above is an extreme simplification but it provides an idea of the process that is happening and what fragmentation is.
Now is when we get into why file systems are different.
FAT maintains a simple table that has to be parsed through as an array to perform an file based operation. It will mercilessly drop files into the first available hole regardless of size. In fact to even tell how much free space is available requires surveying the entire disk.
HPFS and it's childer maintains a bitmap of free space that allows it to quickly scan this bitmap to look for a large enough opening preventing most fragmentation.
Most *nix file systems (notably EXT*) do a complete third option and actually maintain a list of free space, this operation is tightly written into how files are allocated and found and is generally agreed to be a better algorithm than the FAT method.
What this means to you is that fragmentation is a comparatively rare and preventable situation on any EXT* partition. If you do not come to near capacity and stay there then you should never notice it. Now to get into why you can't defragment EXT3.
EXT2 can be defragmented, there is a tool, it almost never gets used in practice as it is usually unnecessary as shutting down your system to fix so small a problem never made sense.
EXT2 is extremely susceptible to a dirty shutdown and anyone who values their files and not take hours to have them hopefully recovered should always take down a EXT2 file system cleanly.
The difference between EXT2 and EXT3 is that EXT3 maintains a file system journal that aids in the recovery of the drive after an unclean shutdown.
This journal however useful however means that defragmenting the drive would require writing a new journal for every change and no one has ever (to my knowledge) seen fit to waste their time and ours on writing something to fix what is almost universally accepted as a non-issue.
You can defragment EXT3 in only one way to my knowledge, by stripping the journal making it an EXT2 file system and running the EXT2 defragmentation utility and then finally generating a new journal returning it to EXT3 status.
Now on to the infamous file system integrity check. This side is much simpler, there is a tool, you just don't need to run it.
The file system maintenance utilities commonly used in *nix environments are old and well respected tools, they will automatically do an integrity scan every x (34 is a common number) mounts of the partition. It is also run any time the the file system is unmounted uncleanly (read someone pulled the plug). This can not normally be prevented and can make 1 in x mounts take a much longer time.
This is in comparison to FAT utilities which are commonly believed to need to be run never and lead to end-user driven runs. I could again get into the difference in the methods of the 2 primary file systems we are comparing here but I will beg you to take my word that a correctly used EXT* partition also generates less file system errors which are easier to clean.
So why not give the end user the tools (I must admit the following is an assumption of mine)? Because they don't need them and will only generate downtime for themselves (as you can not check a mounted drive).
How do you use it correctly you ask? Always wait for a clean take down. ALWAYS!!!
So if you insist on a file system check from a DNS-323 just pull the plug and turn it on, but be prepared to wait for it to finish and be prepared to possibly destroy your data trying to protect it.
In summary yes, EXT* does fragment, no it does not need regular defragmentation. And there are filesystem tools, you just can't access them.
Author
Topic: DEFRAG WITH FIRMWARE 1.03? (Read 9633 times)