|
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.
|
|
|
|
|
Daniel Pfeffer wrote: 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.
That wouldn't afect the "Size on disk" for each file, though.
If you copy to an identically sized disk, it might give you more free space on the disk - but usually not from a better packed MFT! The MFT, with the metadata, is allocated as one huge chunk when the disk is formatted. For identical disks (and using default formatting parameters) they should be the same size. The cleanup gathers the that used records within that file at the start, unused records at the end, but the MFT file has the same file. Only if you at one time have had an excessive number of files on the old disk, so that the MFT had to be extended, may the new disk get away with the orignal MFT size, before it was extended.
There are, however, several other files that normally won't be copied over to the new disk, such as the recycle bin, maybe not the indexing data if your original file was indexed, desktop.ini files (holding icons used by the Explorer) and several other hidden/system files. You may actually loose some data, too, without noticing: Some files may have alternate data streams, and the copyuing method determines if they are preserved. If you go via a FAT disk, they are surely NOT preserved. (On the other hand: Alternate streams are rarely used, and when they are, it is often supplementary data you can do without. It is not as it was on the original Mac OS, before they went Unix, where "file forks" were in common use - forks and alternate streams are similar.) If you copy via FAT, such as by a memory stick, you will also loose any extended metadata - but only in exceptional cases will that save you any disk space when copying the files from the memory stick to then new NTFS disk.
If there old disks had a lot of hidden files, was indexed, and the waste basket was full, then your new disk may have hundred of megabytes of more free space. But each individual file will have the same on-disk size as long as the allocation size is the same.
|
|
|
|
|
Member 7989122 wrote: That wouldn't afect the "Size on disk" for each file, though.
No, it wouldn't. It would, however, affect the total used space on the disk. I doubt the OP compared file sizes for each of the (possibly millions) of files on his disk.
Member 7989122 wrote: The MFT, with the metadata, is allocated as one huge chunk when the disk is formatted.
Wrong. The MFT is allocated with a small initial size (256 entries, in my latest tests), and is expanded as necessary. It is never shrunk. Other metadata - the bitmap, the log, and possibly others are allocated at a fixed size.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Funny that I less than two weeks ago had the same question myself: I copied a fairly large set of small files requiring 6 GBytes on my NTFS disk to a memory stick, where it required 10 GBytes of space.
It burned down to the 32 GByte memory stick being FAT32 formatted with an allocation size of 16 Kbytes. So even the smallest file would require 16 KB on the stick, while it might fit into the MFT entry on NTFS.
I have no memory of formatting the memory stick myself; I think it must have been formatted by the manufacturer. You might argue that if you need a 32GB stick, you probably fill it with media files - sound, photo, video - where 16 KB allocation size is "small" compared to the files sizes, and requires fewer write operations and less index handling. On the avaerage, that holds true for my use of the stick. Increasing the space use by 65% is a very special situation, and after all: Why worry about 4 Mbyte space loss on a 32 GByte medium?
|
|
|
|
|
The software ideologies thread below got me thinking about the flexibility of some people and how well I work with them.
I just got out of a team who wouldn't want to start working on a user story until every little detail was crystal clear (but they still called it agile).
For example:
The story: As an admin I want to see the address of a user on the user overview page.
The questions: How do you want the address formatted? Where on the form do you want to see the address? Do you want address and house number in one field or in two separate fields? Do you want to see the address in that other page too?
That's a very short and simple story, but notice the amount of questions that HAD to be answered before they could put it in a sprint.
Personally, I'd put it in the sprint and I'd ask the story owner about the first three questions. That last question is out of scope, this is about the user overview page, not the other one too.
My current job is the exact opposite.
They want an entire application, possibly with about 10 third party tools, but they don't even know which ones yet (this has been going on for about a year).
And now I can start building... Figuring out the requirements as I go (which is probably about 50% of the job).
For Juun Software, my own business, I got a job "here's a fairly complicated Excel spreadsheet, we want that in an application. Good luck."
Alright, I'll build something, advice about certain subjects, and rebuild it if it's not what the customer wants after all.
Of course with everything clear up front you can make an estimate, you can build what is asked and you'll never have a dispute about if what you built is what they wanted.
With nothing clear it's pretty much impossible to estimate, things will take a lot more time, if your customer is an a**hole he'll give you a hard time for not building what he wanted or taking too long and without the right people these projects tend to fail miserably.
And then there's everything in between.
Personally, I like it when there's some work left for me to figure out. The more the better, like my current project.
Some people really can't deal with that uncertainty though (and when working with them I often find myself thinking "just start building already!").
What's your ideal situation?
|
|
|
|
|
Sander Rossel wrote: How do you want the address formatted?
It is often faster to simply add a setting for those than to go through the ladder and get opinions on how stuff should be formatted. "Just make it configurable" is a good answer to most of those questions, and a good way to teach them not to ask stuff they can answer themselves.
Sander Rossel wrote: Of course with everything clear up front you can make an estimate, you can build what is asked and you'll never have a dispute about if what you built is what they wanted.
Even if the specs are 100% clear, that hardly means that the estimate is correct. I wouldn't wait for the specs to be at 100%; even when old-fashionably waterfalling that's a bit too much (and yes, I still do).
As long as your customer realizes that changes will also mean that the estimates change, you don't need to pour your specs into concrete. Code is very mallable in that respect, cement isn't.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It is often faster to simply add a setting for those
Only if something somewhere is already configurable 
On my current project everything is configurable, as it should be.
I'm not even halfway and it already paid itself back when the customer said "oh yeah, we were thinking we also want this and that" and I was like "you can add it yourself, it's all configurable"
Eddy Vluggen wrote: Even if the specs are 100% clear, that hardly means that the estimate is correct.
It will be when you add the manager modifier of "developer's estimate x 2"
|
|
|
|
|
80/20 rule.
Deliver the bulk of the requirements, the must have, the basic functionality, and put the details, the 'nice to haves' till later. Dont let the second delay the first, thats the key for me.
And every plan can be changed, just make a start, make a decision and head in that direction. If it needs to change mid course, thats OK, at least progress is made.
Thats the way I design SW and run projects, and why I love the scientific method so much. Newtons laws arent perfect, but they are good enough to take man to the moon. For sat nav we need Einstains laws.
'Dont let lack of perfection hold you back' is my lesson from that!
|
|
|
|
|
Munchies_Matt wrote: 'Dont let lack of perfection hold you back' is my lesson from that!
An ex-employer used to say "perfection is the enemy of good enough"
|
|
|
|
|
Let me add that to my list of favourite quotes!
|
|
|
|
|
Good enough begins to make money. Perfection just keeps costing money. This is a fundamental that separates businessmen from programmers.
I'm pretty sure I would not like to live in a world in which I would never be offended.
I am absolutely certain I don't want to live in a world in which you would never be offended.
Freedom doesn't mean the absence of things you don't like.
Dave
|
|
|
|
|
Mind you, those dealing with problems and failures, such as lawyers and doctors, make even more money than those who do good, such is the human condition.
|
|
|
|
|
DRHuff wrote: This is a fundamental that separates businessmen from programmers.
Almost doesn't count*
Depends upon who decides it good enough, doesn't it!
Something about per-ordained third-rate quality that goes against my grain.
Possibly because, although I love getting my check, it's never been about the money. The work you do is your art. Do you want to be proud of what you did or proud of what you got away with?
* (yeah, I know, except in horseshoes)
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
The days are long gone when UI's would be actually storyboarded, though there are some great online tools -- I can't remember the one I used, but there's a plethora of them now. The idea being that all UI elements would be designed, the online storyboarding app that I used, you could click on controls that would actually do things, you could annotate the storyboard with questions, etc.
I found such tools really useful for discovering deficiencies in the UI and the UX. Really helpful to identify those things early.
To me, agile basically means "prototype." OK, there's a "process" part of Agile, but again, that's basically prototype iterations. At some point, the prototype ships, but the project never really started from a solid design.
So my ideal situation is where the UI, UX, data models, etc., are all designed before a single line of code is written. The design tool should then be able to generate UI, code, SQL, and models, leaving the programmer to deal with the real job of gluing it together, performance tweaks, testing, etc.
To me, Agile is just a BS game we play to compensate for the lack of planning but make it look like we know what we're doing. From my experience, anyone that actually has a functional Agile shop or defends Agile is actually doing good software development, and "Agile" is just the name they use because that's what the ignorant masses want to hear.
|
|
|
|
|
|
Marc Clifton wrote: To me, Agile is just a BS game we play to compensate for the lack of planning but make it look like we know what we're doing. From my experience, anyone that actually has a functional Agile shop or defends Agile is actually doing good software development, and "Agile" is just the name they use because that's what the ignorant masses want to hear.
The very idea that I practice "agile" development cracks me up, we have stand ups and the PM used to try and put things into "sprints" and I still keep churning out applications like I have for the last 30 years. The tools have changed but the methodology is basically reiterative waterfall.
I have seen 1 enterprise project that was done with the whole "agile" culture implemented and it worked, even when outsourced to India. I was astonished! Then I found out they used my prototype done in WPF that took me 3 months as the basis of their Java web solution. Took 10 guys 18 months to build. Ok so there was lots of stuff I did not need to implement (eg. security) 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Standups get to me. The idea of "let's punish everyone by making them stand so they won't talk too long" sounds like something from elementary school, not how professionals act.
Just tell the professionals to limit their talk time, take longer discussions offline after the meeting, and have the scrummaster ride herd on the little doggies who forget what professional behavior is.
I refuse to stand in our "stand ups", and when asked why, I merely stated that I am an adult and a professional, and standing up like that is for children.
Then the whole idea of carving out daily meeting time whether it is needed or not, just seems so bureaucratic to me. I call this an article with my views on Agile, but some may call it a rant.
[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
