Jincuteguy
Senior member
NTFS file system is implemented in Window XP/NT, I just want to know what efforts has Microsoft made to provide efficient direct access (also called random access)?
-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
what advantage does NTFS file system have?
- Thread starter Jincuteguy
- Start date
Jincuteguy
Senior member
this is not homeworks, i just want to know if anyone of you know about this
Start by reading the AnandTech FAQ: FAT32 vs NTFS...
Then start looking around for further information on the MFT.
Then start looking around for further information on the MFT.
NogginBoink
Diamond Member
You really should be asking, "what advantages does FAT have over NTFS?"
The answer is very little, if any.
NTFS is faster, more robust, supports ACLs, encryption, compression, uses change journaling, supports more files, folders, and larger filesystems....
The answer is very little, if any.
NTFS is faster, more robust, supports ACLs, encryption, compression, uses change journaling, supports more files, folders, and larger filesystems....
Jeff7181
Lifer
Does compression effect performance? Like if I were to compress a few folders for programs that don't get used very frequently, would the programs open slower? Or maybe faster since not as much info has to be read from the disk and the CPU and decompress it to load it into RAM almost instantly?
Compression ALWAYS slows stuff down. Of course this varies to the type and the amount of compression. You may not be able to notice the difference or have it be a grinding "go watch a TV movie while it starts" ordeal. I don't know about NTFS's stuff though.
If you have lots of RAM, then the performance hit only happens once. Once you get the program running that stuff stays up in the RAM so the next time you use it it doesn't have to re-access the HD again to use it.
If you don't use a app for a while or call up new features or menus, or don't have enough RAM then the computer may have to re-access the compressed file and then you get the performance hit again.
If you have lots of RAM, then the performance hit only happens once. Once you get the program running that stuff stays up in the RAM so the next time you use it it doesn't have to re-access the HD again to use it.
If you don't use a app for a while or call up new features or menus, or don't have enough RAM then the computer may have to re-access the compressed file and then you get the performance hit again.
It probably won't try to load the entire file. Just the parts of it that you use. Don't forget that to a computer everything is just ones and zeros, the boundries between files and types of files are for our benifit only. Just differing levels of abstractions between what you see and the hardware sees. 🙂
So if you have a 500MB text file (plain text file? That's huge. 😛) It will probably be more of a streaming media type of thing, (unless you use it in a text editor, then it will probably load it into a temp file and edit it from there, then write the changes back to the original location when your done.) Meaning that It goes from your HD to RAM to CPU were it's modified then back to RAM then HD, then it doesn't matter so much about how much is going to be in RAM since your only going to access it "once".
Good memory managment dictates that that type of information needs to stay as little time in memory as is needed and save space for applications and stuff that gets read over and over again.
Something like a media file (DVD rip for instance) would suffer the most in terms of performance from running on a compressed partition.
Different types of compression do different things, like compression designed specific for sound files.
If it's a lossy type of compression like MP3's were it actually deletes information based on scientific theory about how the human hears music (loud/high pitched sounds hide lower/softer sounds. IF you can't hear it, then delete it to save space). Then when it is decompressed to be played on a media player it MAY improve percieved performance.
It will use up more CPU cycles then using a plain .wav file, but if you have a REALY crappy HD or are streaming it over the internet you may get better results since it takes less bandwidth to move it around. So you can save disk space, listen to it easier, but ultimate quality will go down and CPU usage will go up.
I suppose it depends on how you quantify "performance".
So if you have a 500MB text file (plain text file? That's huge. 😛) It will probably be more of a streaming media type of thing, (unless you use it in a text editor, then it will probably load it into a temp file and edit it from there, then write the changes back to the original location when your done.) Meaning that It goes from your HD to RAM to CPU were it's modified then back to RAM then HD, then it doesn't matter so much about how much is going to be in RAM since your only going to access it "once".
Good memory managment dictates that that type of information needs to stay as little time in memory as is needed and save space for applications and stuff that gets read over and over again.
Something like a media file (DVD rip for instance) would suffer the most in terms of performance from running on a compressed partition.
Different types of compression do different things, like compression designed specific for sound files.
If it's a lossy type of compression like MP3's were it actually deletes information based on scientific theory about how the human hears music (loud/high pitched sounds hide lower/softer sounds. IF you can't hear it, then delete it to save space). Then when it is decompressed to be played on a media player it MAY improve percieved performance.
It will use up more CPU cycles then using a plain .wav file, but if you have a REALY crappy HD or are streaming it over the internet you may get better results since it takes less bandwidth to move it around. So you can save disk space, listen to it easier, but ultimate quality will go down and CPU usage will go up.
I suppose it depends on how you quantify "performance".
Jeff7181
Lifer
Well I opened it in Notepad... it was 489 MB as a plain uncompressed text file... it took 254 seconds to open it... and it was all in RAM, I could scroll up and down through it... I even checked the task manager to verify that the whole thing was in RAM =)
Then I compressed it and it compressed to 127 MB on the hard drive. So I opened it again and it took 250 seconds to open.
So it looks as though processors can handle it just fine =)
Then I compressed it and it compressed to 127 MB on the hard drive. So I opened it again and it took 250 seconds to open.
So it looks as though processors can handle it just fine =)
Correct me if I've messed up:
HDs stream data at about 33 megabytes per second or faster. 100 M in 3 seconds. 500 M in 15 seconds. So we have some serious overhead to get up to 250 seconds. (1/16 speed?) I wonder what that is?
When disk compression was the rage many years ago, it was generally accepted that the time saving from loading smaller files outweighed the decompression time. Both HDs and processors are far faster today, but processors must have outdone HDs tremendously. For text, the compression factor was 1/10 to 1/20, I believe. The compression for programs was about 1/2. Already compressed files, like jpg, mpg, divx, mp3, and zip, are practically uncompressible. However some of the compression comes from allocating disk blocks with less waste, so small compressed files may show some compression from that.
For a few years W9x had compressed volumes (drvspace, dblspace) built in, but it was phased out and dropped, as HD size outpaced file sizes. (MS paid the major company, Stacker, that developed the compression method MS "imitated", a huge settlement, the greatest windfall that company ever experienced considering that disk compression was worthless within a year or two.)
The primary objection to disk compression was data corruption. The exact cause was undetermined, but people began to shun compression just when it became mainstream. One problem was that the pieces of different files were combined in the same allocation block to eliminate slack. (Slack is the unused space in the last allocation block.) Maybe files were cached too long for that reason, leaving them more subject to not being written to disk during crashes and lockups.
Another oddity was that the reported free space was complete BS, especially when the drive got, say, 80% full. You would see all this space left, write a few small files, and suddenly be out of space. The reported compression rate was partly BS too. The base uncompressed size was not the size of the files added together, but the amount of space it would take to store the files on a volume of twice the HD size, and therefore double the slack.
HDs stream data at about 33 megabytes per second or faster. 100 M in 3 seconds. 500 M in 15 seconds. So we have some serious overhead to get up to 250 seconds. (1/16 speed?) I wonder what that is?
When disk compression was the rage many years ago, it was generally accepted that the time saving from loading smaller files outweighed the decompression time. Both HDs and processors are far faster today, but processors must have outdone HDs tremendously. For text, the compression factor was 1/10 to 1/20, I believe. The compression for programs was about 1/2. Already compressed files, like jpg, mpg, divx, mp3, and zip, are practically uncompressible. However some of the compression comes from allocating disk blocks with less waste, so small compressed files may show some compression from that.
For a few years W9x had compressed volumes (drvspace, dblspace) built in, but it was phased out and dropped, as HD size outpaced file sizes. (MS paid the major company, Stacker, that developed the compression method MS "imitated", a huge settlement, the greatest windfall that company ever experienced considering that disk compression was worthless within a year or two.)
The primary objection to disk compression was data corruption. The exact cause was undetermined, but people began to shun compression just when it became mainstream. One problem was that the pieces of different files were combined in the same allocation block to eliminate slack. (Slack is the unused space in the last allocation block.) Maybe files were cached too long for that reason, leaving them more subject to not being written to disk during crashes and lockups.
Another oddity was that the reported free space was complete BS, especially when the drive got, say, 80% full. You would see all this space left, write a few small files, and suddenly be out of space. The reported compression rate was partly BS too. The base uncompressed size was not the size of the files added together, but the amount of space it would take to store the files on a volume of twice the HD size, and therefore double the slack.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
