Software Engineering Talk Software Engineering Talk    FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  sectors per cluster          Software Engineering Talk Forum Index -> Software Engineering Talk View previous topic :: View next topic   Author Message Benjamin David Lunt Guest Posted: Mon Jun 16, 2008 11:02 am    Post subject: sectors per cluster Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are. However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since data_sectors + cluster_allocation_block = total_sectors Total_sectors is constant, though if data_sectors increases, the cluster_allocation must decrease and visa-versa So, in your past history of reading about file systems, have you come across a way to calculate a cluster size efficiently? I can see doing a fairly close calculation, getting the actual cluster allocation block size and count of clusters, then comparing the amount of dead sectors left behind with the same calculation on the next smaller/larger sized sectors per cluster count until you find a happy medium. I have also seen table driven calculations. If your total disk size is between x and y, then use z as your spc count. However, this gets very inefficient when the table uses large spans between counts. For example, the FAT16 table has a span of 1 gig on its high end for the difference of 32 and 64 sectors per cluster count. Allowing for large disks and small spans, this table could get quite large. Also, some FS's allow any spc count rather than powers of 2. Any comments? Thanks, Ben -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Forever Young Software http://www.frontiernet.net/~fys/index.htm To reply by email, please remove the zzzzzz's Batteries not included, some assembly required. Back to top   Ads Advertising Sponsor Wolfgang Kern Guest Posted: Mon Jun 16, 2008 11:02 am    Post subject: Re: sectors per cluster Benjamin David Lunt wrote: Quote: Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. The only paper on FAT I know are the famous M$-whitepapers. All my FAT ipmort-export relied on this and seemed to work fine, but non-M$ formatted volumes often show slight differences to the given standard. So I found it more reliable to follow the chain from MBR to BR to FAT(s) to ROOT to DATA and calculate the final valid values. Quote: Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. 22 ? Quote: For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are. However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since data_sectors + cluster_allocation_block = total_sectors For DISK-editors I'd add hidden + reserved/wasted + gaps Quote: Total_sectors is constant, though if data_sectors increases, the cluster_allocation must decrease and visa-versa So, in your past history of reading about file systems, have you come across a way to calculate a cluster size efficiently? Efficiency of cluster-size may more depend on expected file sizes ? Quote: I can see doing a fairly close calculation, getting the actual cluster allocation block size and count of clusters, then comparing the amount of dead sectors left behind with the same calculation on the next smaller/larger sized sectors per cluster count until you find a happy medium. Correct sized partitioning may be good for size optimisation, so then there are no gaps and all clusters within sector bounds will be valid. Sure, if a volume spans a whole hard-disk (or the trailing remains) there could be a 'best fitting' cluster-size ... Quote: I have also seen table driven calculations. If your total disk size is between x and y, then use z as your spc count. However, this gets very inefficient when the table uses large spans between counts. For example, the FAT16 table has a span of 1 gig on its high end for the difference of 32 and 64 sectors per cluster count. Allowing for large disks and small spans, this table could get quite large. I have several 2GB FAT16 partitions with 32KB clusters on my disk, the size of the FAT may not hurt, but the wasted trails does. Quote: Also, some FS's allow any spc count rather than powers of 2. Yes, but this shouldn't be called 'FAT' then. I don't have this problem on my OS, because it works on LBA numbers and wont glue sectors to clusters. Granted, a whole volume may be considered as 'one cluster' here. Quote: Any comments? Why use more than sector bound trail-wasting clusters at all ? I think 256 (average half a sector) wasted bytes per file are enough. aren't all these FAT and similar just there to support fragmented read/write ? A heavy delaying story if you ask me. __ wolfgang looks like you already started the thread about FS here me too would like to learn more about NTFS and Linux. Back to top   Ads Advertising Sponsor Alexei A. Frounze Guest Posted: Mon Jun 16, 2008 3:09 pm    Post subject: Re: sectors per cluster On Jun 16, 1:09 am, "Benjamin David Lunt" <zf...@frontiernet.net> wrote: Quote: Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are. However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since data_sectors + cluster_allocation_block = total_sectors Total_sectors is constant, though if data_sectors increases, the cluster_allocation must decrease and visa-versa So, in your past history of reading about file systems, have you come across a way to calculate a cluster size efficiently? I can see doing a fairly close calculation, getting the actual cluster allocation block size and count of clusters, then comparing the amount of dead sectors left behind with the same calculation on the next smaller/larger sized sectors per cluster count until you find a happy medium. I have also seen table driven calculations. If your total disk size is between x and y, then use z as your spc count. However, this gets very inefficient when the table uses large spans between counts. For example, the FAT16 table has a span of 1 gig on its high end for the difference of 32 and 64 sectors per cluster count. Allowing for large disks and small spans, this table could get quite large. Also, some FS's allow any spc count rather than powers of 2. Any comments? Thanks, Ben All my FAT calculations in my latest code are base on the MS documents. Look at it, if you need. Long time ago I'd used some information from various places and one Russian book that described the details of FAT and provided some Pascal code to read/write the structures and clusters. However, all that old info was partially reverse-engineered and guessed. It was off by something in several places. FAT is known to be very inefficient when it comes to large disks. The larger the disk, the larger is the table and the longer is file/dir search and the more space is left unused at the end of last clusters. Whatever you choose, it's far from being optimal. As for deviations from the MS document and non-power-of-2 counts, double check the document to make sure your code is compliant. And try not to do something funky -- you never know how somebody else's FAT code is screwed, what it assumes and relies on. Alex Back to top   Ads Advertising Sponsor Benjamin David Lunt Guest Posted: Mon Jun 16, 2008 10:53 pm    Post subject: Re: sectors per cluster "Benjamin David Lunt" <zfysz@frontiernet.net> wrote in message news:vep5k.3245$qE5.2404@fe107.usenetserver.com... Quote: Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are. However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since data_sectors + cluster_allocation_block = total_sectors Total_sectors is constant, though if data_sectors increases, the cluster_allocation must decrease and visa-versa So, in your past history of reading about file systems, have you come across a way to calculate a cluster size efficiently? I can see doing a fairly close calculation, getting the actual cluster allocation block size and count of clusters, then comparing the amount of dead sectors left behind with the same calculation on the next smaller/larger sized sectors per cluster count until you find a happy medium. I have also seen table driven calculations. If your total disk size is between x and y, then use z as your spc count. However, this gets very inefficient when the table uses large spans between counts. For example, the FAT16 table has a span of 1 gig on its high end for the difference of 32 and 64 sectors per cluster count. Allowing for large disks and small spans, this table could get quite large. Also, some FS's allow any spc count rather than powers of 2. Hi guys, I guess I may not have been quite as clear as I should have been. I am not talking about (MS) FAT specifically. I am talking about any cluster based FS in general. At format time, when you are to calculate how many sectors per cluster you will give to this partition, how do you calculate it? For example, the FYSFAT FS uses 128 byte slots to store 28 32-bit cluster numbers. If I have a partition of 1 gig, and sectors are 512 bytes each, this would take 2097152 cluster numbers, 74899 128 byte slots, or 18725 sectors for the FAT allocation of the disk. This would also use 512 sectors for a 1-bit per cluster bitmap. Not counting boot, super block, multiple bitmaps, etc., this would use 19237 sectors. Now, if I simply recalculate that to use 8 sectors per cluster, this would now only take 2341 sectors for the FAT allocation. This gives 16384 sectors more in the data block. However, to put this to code, the following is a catch 22. (http://en.wikipedia.org/wiki/Catch-22) unsigned spc = a_calculation_on(data_block_size); unsigned data_block_size = (total_sectors - reserved - fat - bitmaps); However, as you know, the more spc there are, the less sectors you will use for FAT and bitmaps. So to figure out the size of the data block you need to know spc. To figure out spc, you need to know the size of the data block. This is what I am trying to do and do efficiently. Thanks, Ben Back to top   Ads Advertising Sponsor Mark L Pappin Guest Posted: Tue Jun 17, 2008 2:13 am    Post subject: Re: sectors per cluster (off-topic digression) "Wolfgang Kern" <nowhere@never.at> writes: Quote: Benjamin David Lunt wrote: Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. 22 ? See http://en.wikipedia.org/wiki/Catch-22 Used in this context to mean "circular dependency". It's a common idiom in English, even among people who haven't read the book. mlp Back to top   Ads Advertising Sponsor Rod Pemberton Guest Posted: Tue Jun 17, 2008 5:48 am    Post subject: Re: sectors per cluster "Benjamin David Lunt" <zfysz@frontiernet.net> wrote in message news:vep5k.3245$qE5.2404@fe107.usenetserver.com... Quote: Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are. However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since Having read both posts, I think I found your catch-22 problem. But, I don't know if the "solution" will work with existing filesystems. You're using just the "data clusters" to calculate the cluster size instead of the "total disk clusters" or the entire disk space. I.e., you need a fixed value to calculate from and the size of the disk (or partition) is the only thing that is fixed. So, IMO, the calculation for the cluster size should include the entire disk capacity (or partition). My perspective is based on the idea that the special sectors: FAT, reserved, bitmaps, etc., are a relatively small percentage of the total disk space versus the "data clusters". It doesn't really matter if "non-data clusters" consume a few entries in the allocation method, does it? Rod Pemberton Back to top   Ads Advertising Sponsor Benjamin David Lunt Guest Posted: Tue Jun 17, 2008 7:35 am    Post subject: Re: sectors per cluster "Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message news:g371on$nl5$1@aioe.org... Quote: "Benjamin David Lunt" <zfysz@frontiernet.net> wrote in message news:vep5k.3245$qE5.2404@fe107.usenetserver.com... Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are. However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since Having read both posts, I think I found your catch-22 problem. But, I don't know if the "solution" will work with existing filesystems. You're using just the "data clusters" to calculate the cluster size instead of the "total disk clusters" or the entire disk space. I.e., you need a fixed value to calculate from and the size of the disk (or partition) is the only thing that is fixed. So, IMO, the calculation for the cluster size should include the entire disk capacity (or partition). My perspective is based on the idea that the special sectors: FAT, reserved, bitmaps, etc., are a relatively small percentage of the total disk space versus the "data clusters". It doesn't really matter if "non-data clusters" consume a few entries in the allocation method, does it? Hi Rod, Ya, you are just about right. However, I was wondering if there was a way to save those sectors. Now for the easy question, what is the usual cluster size for a given partition size. i.e.: how does one usually calculate the cluster size given a partition size? A lookup table? A math equation? What is the usual, most popular way to calculate the spc amount. Thanks, Ben Back to top   Ads Advertising Sponsor Wolfgang Kern Guest Posted: Tue Jun 17, 2008 11:03 am    Post subject: Re: sectors per cluster Mark L Pappin informed me: Quote: (off-topic digression) "Wolfgang Kern" <nowhere@never.at> writes: Benjamin David Lunt wrote: Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. 22 ? See http://en.wikipedia.org/wiki/Catch-22 Used in this context to mean "circular dependency". It's a common idiom in English, even among people who haven't read the book. Oh.. I see, thanks __ wolfgang Back to top   Ads Advertising Sponsor Rod Pemberton Guest Posted: Tue Jun 17, 2008 11:03 am    Post subject: Re: sectors per cluster "Benjamin David Lunt" <zfysz@frontiernet.net> wrote in message news:urF5k.3$5y2.0@fe113.usenetserver.com... Quote: "Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message news:g371on$nl5$1@aioe.org... "Benjamin David Lunt" <zfysz@frontiernet.net> wrote in message news:vep5k.3245$qE5.2404@fe107.usenetserver.com... Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are. However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since Having read both posts, I think I found your catch-22 problem. But, I don't know if the "solution" will work with existing filesystems. You're using just the "data clusters" to calculate the cluster size instead of the "total disk clusters" or the entire disk space. I.e., you need a fixed value to calculate from and the size of the disk (or partition) is the only thing that is fixed. So, IMO, the calculation for the cluster size should include the entire disk capacity (or partition). My perspective is based on the idea that the special sectors: FAT, reserved, bitmaps, etc., are a relatively small percentage of the total disk space versus the "data clusters". It doesn't really matter if "non-data clusters" consume a few entries in the allocation method, does it? Hi Rod, Ya, you are just about right. However, I was wondering if there was a way to save those sectors. If you know the per cluster space used by the allocation method and the disk size, you can calculate the size of the FAT, bitmap, data block, etc. total_sectors=reserved_sectors+data_block_sectors+data_block_sectors*(per_cl uster_FAT_size_in_fractional_sectors+per_cluster_bitmap_size_in_fractional_s ectors) where data_block_sectors=data_block_clusters*clusters_per_sector E.g., for your FYSFAT 1 gig partition: data_block_size=(2097152 sectors - 0 reserved)/(1+(4+(16/2)/512 + (1//512)= 2078090 data sectors FAT_size=((4+(16/2)/512)*data_block_size=18554 (vs. 18725) (i.e., approx. 145 128 byte slots vs. approx. 146 128 byte slots ) Quote: For example, the FYSFAT FS uses 128 byte slots to store 28 32-bit cluster numbers. 128 bytes / 4 bytes = 32 (not 28) 4 values used for maintenance? (i.e., 4*4=16 maintenance bytes / 28 values...) Quote: Now for the easy question, what is the usual cluster size for a given partition size. To me, a cluster is a FAT concept. A cluster is a group of sectors used to reduce the space requirements of the allocation map to something reasonable or to improve disk size scalability without increasing space requirements. cluster=(2^n)*512, n=0,1,2,3,4,5,6,7... where n is "best fit" to the allocation method or space requirements Rod Pemberton Back to top   Ads Advertising Sponsor octavio Guest Posted: Tue Jun 17, 2008 6:32 pm    Post subject: Re: sectors per cluster On Jun 17, 4:35 am, "Benjamin David Lunt" <zf...@frontiernet.net> wrote: Quote: "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message news:g371on$nl5$1@aioe.org... "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message news:vep5k.3245$qE5.2404@fe107.usenetserver.com... Throughout my File System work, I haven't seen many actual formula's or papers on how to calculate how many sectors per cluster a particular sized partition should use. Without being File System dependant, I have found that the calculation of actual data sectors is a catch 22. For instance, the size of the bitmap, FAT, or whatever type of cluster allocation is used, is based on how many data clusters there are.  However, to get the amount of data clusters, you need to know the size of the bitmap, FAT, or cluster allocation space, since Having read both posts, I think I found your catch-22 problem.  But, I don't know if the "solution" will work with existing filesystems.  You're using just the "data clusters" to calculate the cluster size instead of the "total disk clusters" or the entire disk space.  I.e., you need a fixed value to calculate from and the size of the disk (or partition) is the only thing that is fixed.  So, IMO, the calculation for the cluster size should include the entire disk capacity (or partition).  My perspective is based on the idea that the special sectors: FAT, reserved, bitmaps, etc., are a relatively small percentage of the total disk space versus the "data clusters".  It doesn't really matter if "non-data clusters" consume a few entries in the allocation method, does it? Hi Rod,  Ya, you are just about right.  However, I was wondering if there was a way to save those sectors. Now for the easy question, what is the usual cluster size for a given partition size.  i.e.: how does one usually calculate the cluster size given a partition size?  A lookup table?  A math equation?  What is the usual, most popular way to calculate the spc amount. Thanks, Ben- Hide quoted text - - Show quoted text - I use a kind of logarithm of the partition size, smaller partition use 1 sector per cluster when size multiplies by 8 (as example), the cluster size is doubled,as for other calculations i use succesive aproximations recreassing the number of clusters on each loop,speed is not important in this case. Back to top   Ads Advertising Sponsor Benjamin David Lunt Guest Posted: Tue Jun 17, 2008 11:31 pm    Post subject: Re: sectors per cluster "Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message news:g382r0$78q$1@aioe.org... Quote: Hi Rod, No, my questions was easier than that All I wan't to know is: If I have X amount of sectors, what would be the nominal count for a cluster size. i.e.: If I have X sectors, what should the cluster size be? Thats it. Should I use a table: const struct SPC_TABLE { bit32u size; // megs bit16u spc; // sectors per cluster } spc_table[] = { { 16, 1 }, // 16 meg or less uses 1 sector per cluster { 128, 4 }, // 128 meg " " " 4 " " " { 256, 8 }, // 256 meg ... { 512, 16 }, // 512 meg ... { 1024, 32 }, // 1 gig ... { 2048, 64 }, // 2 gig ... { 16384, 128 }, // 16 gig ... { 131072, 256 }, // 128 gig ... { 524288, 512 }, // 512 gig (1/2 terra byte) (2097152 clusters) { 0, 0 } // table end marker }; Then loop through the table until the partition size is less than spc_table[i].size, then use spc_table[i].spc? If so, what are the nominal, best used values to place in the table? Or is there a different prefered method? This is the answer I am looking for. Sorry for the confusion. Quote: For example, the FYSFAT FS uses 128 byte slots to store 28 32-bit cluster numbers. 128 bytes / 4 bytes = 32 (not 2 The first 16 bytes are used for slot continue, previous, crc, entry count, flags, etc. 16 + (28 * 32bit_entry) = 128 or 16 + (14 * 64_bit_entry) = 128. Quote: 4 values used for maintenance? (i.e., 4*4=16 maintenance bytes / 28 values...) Now for the easy question, what is the usual cluster size for a given partition size. To me, a cluster is a FAT concept. A cluster is a group of sectors used to reduce the space requirements of the allocation map to something reasonable or to improve disk size scalability without increasing space requirements. Exactly. Quote: cluster=(2^n)*512, n=0,1,2,3,4,5,6,7... where n is "best fit" to the allocation method or space requirements Yep. Thanks, Ben Back to top   Ads Advertising Sponsor Rod Pemberton Guest Posted: Wed Jun 18, 2008 6:24 am    Post subject: Re: sectors per cluster "Benjamin David Lunt" <zfysz@frontiernet.net> wrote in message news:urT5k.435$aQ3.388@fe085.usenetserver.com... Quote: "Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message news:g382r0$78q$1@aioe.org... If I have X amount of sectors, what would be the nominal count for a cluster size. i.e.: If I have X sectors, what should the cluster size be? Thats it. It depends on the FS implementation, doesn't it? I'm not sure a "one size fits all" solution exists. Quote: Should I use a table: That would work FS that varies cluster or block size based on disk capacity. Quote: const struct SPC_TABLE { bit32u size; // megs bit16u spc; // sectors per cluster } spc_table[] = { { 16, 1 }, // 16 meg or less uses 1 sector per cluster { 128, 4 }, // 128 meg " " " 4 " " " { 256, 8 }, // 256 meg ... { 512, 16 }, // 512 meg ... { 1024, 32 }, // 1 gig ... { 2048, 64 }, // 2 gig ... { 16384, 128 }, // 16 gig ... { 131072, 256 }, // 128 gig ... { 524288, 512 }, // 512 gig (1/2 terra byte) (2097152 clusters) { 0, 0 } // table end marker }; Then loop through the table until the partition size is less than spc_table[i].size, then use spc_table[i].spc? If so, what are the nominal, best used values to place in the table? Or is there a different prefered method? This is the answer I am looking for. Sorry for the confusion. -- EXT2 "Linux does not support a block size greater than page size, which is 4kb on Intel-based, 32-bitsystems." .... "On 32-bit hardware, linux file systems have a maximum effective block size of 4kb. Most allow usage of smaller block sizes with the minimum size being equal to the harddisk sector size of 512 bytes" http://www.unisys.com/products/insights/insights__compendium/Linux_File_Systems_Comparative_Performance_White_Paper_1-6-06.pdf -- NTFS can be specified by the user. If not specified, NTFS uses a default size from a table based on the disk size: http://support.microsoft.com/kb/140365 (Link also includes cluster sizes for nearly all other MS OSes!!!) -- FAT for floppy and hard disks need table(s) based on disk size: "FAT Volume Initialization At this point, the careful reader should have one very interesting question. Given that the FAT type (FAT12, FAT16, or FAT32) is dependant on the number of clusters and that the sectors available in the data area of a FAT volume is dependant on the size of the FAT when handed an unformatted volume that does not yet have a BPB, how do you determine all this and compute the proper values to put in BPB_SecPerClus and either BPB_FATSz16 or BPB_FATSz32? The way Microsoft operating systems do this is with a fixed value, several tables, and a clever piece of arithmetic." Microsoft Extensible Firmware Initiative FAT32 File System Specification, fatgen103.pdf fatgen103.pdf uses the disk size and two lookup tables: "So given a disk size and a FAT type of FAT16 or FAT32, we now have a BPB_SecPerClus value..." Also, FAT cluster sizes: http://support.microsoft.com/kb/67321 All I've got... Rod Pemberton Back to top   Ads Advertising Sponsor Benjamin David Lunt Guest Posted: Wed Jun 18, 2008 9:00 am    Post subject: Re: sectors per cluster "Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message news:g39o8s$ngl$1@aioe.org... Quote: "Benjamin David Lunt" <zfysz@frontiernet.net> wrote in message news:urT5k.435$aQ3.388@fe085.usenetserver.com... "Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message news:g382r0$78q$1@aioe.org... If I have X amount of sectors, what would be the nominal count for a cluster size. i.e.: If I have X sectors, what should the cluster size be? Thats it. It depends on the FS implementation, doesn't it? I'm not sure a "one size fits all" solution exists. Your absolutely right. I was hoping for a general idea of cluster sizes. Quote: -- EXT2 "Linux does not support a block size greater than page size, which is 4kb on Intel-based, 32-bitsystems." ... "On 32-bit hardware, linux file systems have a maximum effective block size of 4kb. Most allow usage of smaller block sizes with the minimum size being equal to the harddisk sector size of 512 bytes" http://www.unisys.com/products/insights/insights__compendium/Linux_File_Systems_Comparative_Performance_White_Paper_1-6-06.pdf -- NTFS can be specified by the user. If not specified, NTFS uses a default size from a table based on the disk size: http://support.microsoft.com/kb/140365 (Link also includes cluster sizes for nearly all other MS OSes!!!) -- FAT for floppy and hard disks need table(s) based on disk size: "FAT Volume Initialization At this point, the careful reader should have one very interesting question. Given that the FAT type (FAT12, FAT16, or FAT32) is dependant on the number of clusters and that the sectors available in the data area of a FAT volume is dependant on the size of the FAT when handed an unformatted volume that does not yet have a BPB, how do you determine all this and compute the proper values to put in BPB_SecPerClus and either BPB_FATSz16 or BPB_FATSz32? The way Microsoft operating systems do this is with a fixed value, several tables, and a clever piece of arithmetic." Microsoft Extensible Firmware Initiative FAT32 File System Specification, fatgen103.pdf fatgen103.pdf uses the disk size and two lookup tables: "So given a disk size and a FAT type of FAT16 or FAT32, we now have a BPB_SecPerClus value..." Also, FAT cluster sizes: http://support.microsoft.com/kb/67321 I will take these items into consideration when I adjust my table. Thanks again, Ben Back to top   Ads Advertising Sponsor Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         Software Engineering Talk Forum Index -> Software Engineering Talk All times are GMT Page 1 of 1   Jump to: Select a forum Software Engineering Talk----------------Software Engineering Talk  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Australian Debt Consolidation Experts medical insurance Wedding Annunci di topclassescort con foto e numeri di telefono in tutta Italia Swingers in Germany Call Centers Cheap Car Insurance Make Your Own Website Cheap phone calls to UAE Cleaning Service mold killer UK Swingers Genuine Contacts Site Janitorial Supplies Eureka Vacuum Bags 130 Attacks blocked Powered by phpBB © 2001, 2005 phpBB Group