OSDev.org

i've done some reading on fat32. not sure how ntfs is setup but sounds more complicated than i care to understand.

for those that might not understand the section. i have a thought to devide the hard drive logically into different sections of the hard drive. i figure the the end of the hard drive is the hardest part to seek to and the nearest the easiest each with its own sectors per cluster assignment. the sections would be based off a cylinder bases. the first sector would have multiple file fragments per sector as to save space which is the whole idea of the sectoins.

any comments on anything or suggestions would be nice.

anyways
directory structure-
numbers of files in directory
starting location of file table
len of array for files in root directory
index of file offset locations

data structure-
index pointing to file data section offsetslen of name
filetype - (folder, file, hidden, system, (global read write attributes, group read write attributes, user read write attributes)
if folder pointer to folder table - otherwise null
file name - byte array
section index - if section 1 the offset into the sector and len
section array
section number
array of clusters
len of cluster array
cluster array
len of crossfile references array
references index
references array

Ninjarider wrote:i've done some reading on fat32. not sure how ntfs is setup but sounds more complicated than i care to understand.

for those that might not understand the section. i have a thought to devide the hard drive logically into different sections of the hard drive. i figure the the end of the hard drive is the hardest part to seek to and the nearest the easiest each with its own sectors per cluster assignment. the sections would be based off a cylinder bases. the first sector would have multiple file fragments per sector as to save space which is the whole idea of the sectoins.

Moving the head to some position has always the same speed. So inside or outside doesn't matter. Only distance does. Rotating the platter to where you want to read/write also is constant. On average you need half a rotation for the right part to come under the head.

What you probably ment is that the data density on the inside is less so the data throughput is less. read/writes will be faster on the outside than inside.


Next you have a problem with cylinder boundaries. For obvious reasons it would be nice to align your filesystem to cylinder boundaries. But where are they? Cylinder will have a variable number of sectors and there is no way to get to that information. The CHS geometry nowadays is purely virtual and in no way reflects the harddisks geometry. And LBA modes don't even pretend to give any geometry informations.

So unless you want to do extensive performance test on the disk to figure out where cylinder boundaries are just ignore them.

Ninjarider wrote:any comments on anything or suggestions would be nice.

Maybe look into phase trees or journaling filesystems. Sure they are way more complex but loosing filesystem data and/or lengthy filesystem checks are awfull. Users expect better nowadays.

MfG
Mrvn

how to access a hard drive to utilize the lba in assembly

Was that a question? - If so, STFW

Ninjarider wrote:how to access a hard drive to utilize the lba in assembly

That's why I use XEN.

??stfw?? huh

STFW = Search The Fu*king Web.

check out osdever.net for some stuff on LBA

had the file on my drive just didn't know what i was looking at. so its still int 13h but extended functions.

anyways. what is an effiecent way of having multiple entries in a file system to the same file?

The common way would be to separate the directory structure from file data, by using inodes. Inodes are the structures that point to the file data and how often they are referenced. The directory tables hold filenames and a pointer to an inode.

should i store the file name in the directory data or in the file data or both.

To my knowledge there are both concepts, but for inode-based filesystems, it's more common to store filenames in a directory entry (which is bound to a directory inode), and have the directory entry point to the actual file's inode.

i think thats got a little more shape to it than my original post.

can any body think of some ways to lean it up.
can anyone see and faults.


IFS_Root_Structure
RS_DirBlock dd 0
RS_FileBlock dd 0

IFS_Data_Structure ;Data structure would be used for both directory and file blocks
DS_StructLen db 0 ;Multiply by 64 for actual structure length
DS_Array1Offset db 0 ;The offset address to the RefArray
DS_Array2Offset db 0 ;The offset address to the FileName
DS_CreatedStamp dd 0 ;created stamp is counted in seconds
DS_ModifieStamp dd 0 ;counted in seconds
DS_AccessStamp dd 0 ;counted in seconds
DS_TypePriv dd 0 ;file/folder type as far as hidden, system, and user read and write privileges
DS_Blocks dq 0 ;if used for directory would point to next inode. for file would point to the file data blocks.
DS_RefArray dq 0
DS_FileName db 0