|
Fortunately - for Roy - Lanolin is still a vegetarian...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Colours one short of a deck for the most part (6)
One short of a deck = 51 = LI
For the most part = VERY
Giving LIVERY = COLOURS
98.4% of statistics are made up on the spot.
modified 21-May-18 9:32am.
|
|
|
|
|
shades?
one short of spades?
|
|
|
|
|
Nope
98.4% of statistics are made up on the spot.
|
|
|
|
|
Tracer?
One short of deck: Terrac[e]
Anag: Tracer
Colours: Flow tracer
A tad far fetched but...
... such stuff as dreams are made on
|
|
|
|
|
Nope.
98.4% of statistics are made up on the spot.
|
|
|
|
|
So what was it? I'm stumped.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
"hubris"...
hue (one short) - colours
bris - of a deck... of wait... I read that wrong
|
|
|
|
|
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Duncan Edwards Jones wrote: bris
Care to explain that to a non-Englisher?
... such stuff as dreams are made on
|
|
|
|
|
erm… I shall have to read carefully.. it is a word for a religious ceremony that is only performed on the male children.
|
|
|
|
|
I am about to a complete reformat on my rig, and am saving everything to some external drives. However, it seems although the "Size" and # of files match up, the "Size on disk" is off a little bit. Is this indicative of a drive that is about to fail?
|
|
|
|
|
Hi,
Files can be stored on the drive in multiple ways... here are some examples that will cause differing 'Size on Disk'.
FileA.txt stored on Drive A:
If you store a 1KB file (such as small source code file) on a NTFS partition with 4KB (default) sector size... then the 1KB file has a 4KB 'Size on Disk'. The sector unfortunately has 3KB of wasted space.
FileB.txt stored on Drive B:
If you copy that 1kb file and paste it onto an external drive... and that drive saves the file directly into the $MFT then that 1KB file takes 1KB of space.
Right clicking in Explorer on the file in FileA.txt will have '4KB Size on Disk' and right clicking on FileB.txt it will have '1KB Size on Disk'.
Multiply that 3KB difference by a few thousand small source code files and your folders can have large differences in the size reported on disk.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: FileB.txt stored on Drive B:
If you copy that 1kb file and paste it onto an external drive... and that drive saves the file directly into the $MFT then that 1KB file takes 1KB of space. That 1K in the MFT is spent in both cases, for the metadata. On disk A the total space consumption is 5K, but you won't notice it because the MFT is allocated in huge chunks, one really huge one when the volume is formatted. That 1K entry is just a block within that already allocated file.
Furtermore: If the file metatdata requires, say, 400 bytes, there is only 600 bytes left for file data, and a 1K file won't fit in but requires a separate 4K disk page - or whatever the allocation size is for that disk. On my 32 GB memory stick, for some reason the allocation size is 16K. (I could reformat it, but if I fill it up with 32 GB, that will be with huge files where 8K space loss at the end, on the average, is a drop in the ocean. The benefit of fewer units to retrieve outweighs the space loss.)
|
|
|
|
|
Member 7989122 wrote: That 1K in the MFT is spent in both cases, for the metadata.
You are almost correct.
Any and all files saved on an NTFS partition will result in a 1024 byte MFT entry. So it would be correct to say that all files saved on your NTFS partition have an additional overhead of 1024 bytes for the MFT entry. But if we want to get more technically correct... it *could* result in an additional 2048 bytes if we consider the $MFTMirror.
Member 7989122 wrote: Furtermore: If the file metatdata requires, say, 400 bytes, there is only 600 bytes left for file data, and a 1K file won't fit in but requires a separate 4K disk page - or whatever the allocation size is for that disk.
Correct, what happens in this case is that the filesystem driver saves the file directly into a cluster. If that cluster happens to be allocated at 16K then you'll have 15K wasted. + 1K for the MFT overhead and a possible entry into the $MFTMirror for another 1K.
Keep in mind that the topic here is 'Why does explorer report different 'Size on Disk' sizes?'
The answer is that explorer looks at NTFS cluster size, and also whether or not that file has been saved into a cluster. It will correctly round up to the cluster size to take into account the wasted space. If the file has not been saved into a disk cluster it reports the size of a single MFT entry (only on NTFS). Explorer does not even consider the $MFTMirror or take that into account.
There are even more caveats... on a regular file saved into a disk cluster... Explorer only reports the size of the disk clusters and does not report the 1K MFT overhead.
Best Wishes,
-David Delaune
|
|
|
|
|
Not necessarily.
One possibility is that the cluster size of the disks differs. The cluster size is the smallest unit that Windows will allocate on a disk, and if this differs between the disks, the amount of disk space taken by a file may differ, too.
Another possibility is that the disks don'the use the same file system. If one uses NTFS and the other uses FAT32, the meta data stored for each file differs in size, and so will the total space taken.
Lastly, your old disk may have unused areas within the meta data files - over time, files were deleted, created, and some of the meta data area was left unused. When copying the files to a new disk, any such gaps are eliminated.
If you are still worried, run CHKDSK on the disk. This should tell you if any errors exist. If they do, run CHKDSK /F, which will fix the errors.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: The cluster size is the smallest unit that Windows will allocate on a disk ... because the space for the directory is always the same size, no matter how many sectors the disk has. Things quickly become wasteful when your drive (or partition) is too large and when you have many small files.
I hope I find a good balance when I get to implement my file system on the computer I'm building. 8 bit computers usually have small files, but the 'drives' will be up to 128 Gb.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
As far as the file system is concerned, directories are only files with special contents. The only exception is the root directory, which is treated differently on FAT file systems. As such, these "files" are subject to the same growth limitations as other files.
Even the ext family of file systems treats directories as "files". They, of course, store most essential metadara in inodes.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
CodeWraith wrote: ... because the space for the directory is always the same size, no matter how many sectors the disk has. Usually.
When a disk is NTFS formatted, a sizable chunk is set aside for the directory, or "Master File Table" (MFT) - usually a lot more than you need. But it could overflow, and in that case, NTFS will extend the MFT, occupying more space. That doesn't happen every day, though.
|
|
|
|
|
Daniel Pfeffer wrote: The cluster size is the smallest unit that Windows will allocate on a disk, and if this differs between the disks, the amount of disk space taken by a file may differ, too.
Which is not completely true on NTFS partitions where thousands of small files can be stored directly into the MFT. Cluster size on NTFS can be 4KB and files <=1KB can be stored directly into the MFT.
However your statement is true for FAT,FAT16,FAT32 exFAT and ReFS.
Best Wishes,
-David Delaune
|
|
|
|
|
True, but my message was already more than long enough, without going into the more esoteric details of NTFS.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Well... Files significantly less than 1K may be stored in MFT. Each directory entry is alotted a 1K block, and a varying part of this block is used for file metadata. Whatever space is left after the metadata has taken their part can be used for file data that fits in. If it doesn't fit in, it all goes to a 4K disk page.
If you have a lot of extended attributes for a file, the 1K block may overflow and a second one linked to it. But in no case will you have a full 1024 bytes for file data in the MFT; just "the rest of the block".
|
|
|
|
|
Hi,
You are absolutely correct that the Microsoft NTFS filesystem driver requires that the file be significantly less than 1K to be stored in the MFT. The file attributes and metedata need a place to live!
Best Wishes,
-David Delaune
Edit:
I am the author of multiple filesystem filter drivers. Some of my cryptic statements are a result of having too much experience in this area. My reason for stating <= 1KB is from my experience of saving a 1MB file in 1000 MFT entries. Why do such a dumb thing? For science! (security research)
Best Wishes,
-David Delaune
modified 21-May-18 19:13pm.
|
|
|
|