On Sat, Jan 10, 2009 at 10:46 AM, Sandeep K Sinha <sandeepksinha@xxxxxxxxx> wrote: > On Sat, Jan 10, 2009 at 8:36 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: >> On Sat, Jan 10, 2009 at 1:43 PM, Sandeep K Sinha >> <sandeepksinha@xxxxxxxxx> wrote: >>> Well, >>> >>> I don't understand the reason why we keep the number of blocks in >>> multiple of 512 bytes. >> >> I guess because that is generally the default sector size, and to do a >> bio you really deal in terms of sectors not blocks. >> > > IMHO, I think this should go now. The calculations in terms of 512 > bytes sector size while operating with bio can be done there as well. > If we have the block size and number, we can calculate the required > info at any point. > > The current implementation just gives a wrong meaning as "no of > allocated blocks". This should just be the number in terms of the file > system block size. >> Thanks - >> Manish Can be argued either way, but a sector is the unit of atomicity with a disk drive. ie. You can not read/write data smaller than a sector. To do so, you have to implement a read/modify/write sequence to the physical drive. Thus using sectors for disk based storage is very logical, especially historically. The other side of the coin is that drives with 4K sectors may soon start appearing, so restructuring the code to reference 4K blocks/pages instead of sectors also makes good sense. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
