sector mgmt
sector mgmt
my lecturer said that the disk sector management should be handled by the kernel itself and not the driver. i haven't yet decided to enable writing, because even a simple mistake could lead to the loss of information and none of you will ever want to test an os which will write to the disk. so let me know whether allocating sector information should be handled by kernel. but if it is to be handled by the kernel then we have to be fixed to specific file system, isn't it?
everyone here are best programmers ( not yet not yet)
A couple of questions:
What type of kernel are you writing? In a microkernel, putting anything relating to disks in the kernel would be a mistake. Other kernels, perhaps...
By "sector management", what exactly do you mean? Do you mean to say pulling data from a disk sector that's been mapped to a memory block (typically in response to a page fault) and flushing dirty blocks back to disk after use? Or allocating sectors on the disk for writing files to? As an example, the Linux kernel does the former in core kernel code, but the latter in the filesystem driver (which may be a module).
What type of kernel are you writing? In a microkernel, putting anything relating to disks in the kernel would be a mistake. Other kernels, perhaps...
By "sector management", what exactly do you mean? Do you mean to say pulling data from a disk sector that's been mapped to a memory block (typically in response to a page fault) and flushing dirty blocks back to disk after use? Or allocating sectors on the disk for writing files to? As an example, the Linux kernel does the former in core kernel code, but the latter in the filesystem driver (which may be a module).
I don't know what he meant, but the way I do it is like this: I have an i/o block driver, it basically just tells me the sector size and sector count of the device (as well as if it has support to read/write, and some other stuff, like removeable, fixed, etc), and gives me a function to read a sector (or multiple sectors) at a time. My disk driver has a list of devices that were found, and checks each for a partition table, if one exists, it splits it again, and stores the starting location and size of each. At this point, it then checks each valid disk/partition for what filesystem driver can load it by calling the file system's CanSupport function with the first sector of each partition. I now have a list of what are valid disks, valid partitions, and a list of which fs is for which partition/disk. When one of my apps makes a call to the kernel to open a file for read, my kernel sends this to my disk driver, which checks to see if a valid FS was found for this device. If it was, it sends control over to the FS letting it know we want to open a file for read. The FS driver does it's thing by reading the disk using the block i/o driver that is specific to that device. So, there are a lot of links in there, and a lot of people getting their hands dirty just to read some data, but it abstracts the FS from the device type completely. I can use a Fat32 driver on a zip drive, flash drive, hard disk, ram disk, whatever I wanted without it caring one bit. I think I may rework some of my back-links and layout to make it a bit simpler to read, but the concept will remain pretty much the same.
by "sector management" i meant allocating, deallocating sectors etc.
No. if your fs driver needs to ceate a file then sectors needs to be allocated, will it be handled by your kernel or the fs driver itself?Do you mean to say pulling data from a disk sector that's been mapped to a memory block (typically in response to a page fault) and flushing dirty blocks back to disk after use?
everyone here are best programmers ( not yet not yet)
if the sectors are allocated for a file in some pattern, it will be retrieved from the disk quickly. i.e by making disk scheduling we can reduce the time taken to read a file. Implementing disk scheduling in the fs driver seems odd, thus if allocation of sector is done by the kernel then it is possible to perform disk scheduling. As a kernel developer we cannot assume that the driver 
will come along with some form of disk scheduling.
regards,
pradeep.
will come along with some form of disk scheduling.regards,
pradeep.
everyone here are best programmers ( not yet not yet)
Yes.Most of the time taken to read from a HD is used for seeking.So if a file is stored entirely in continuous sectors the reading time can be reduced.But most disk scheduling algorithms work well at first and few will keep the same efficiency when the disk has been operated for some time(I mean few would last long,but you've heard of other better ones...pulsar wrote:if the sectors are allocated for a file in some pattern, it will be retrieved from the disk quickly.
).So regular disk descattering may help to make it almost as fast as it was.What's wrong if you implement that as a driver(other than a kernel)?Linux can link its modules to the kernel either in a static or a dynamic way so once they're registered they can be regarded as part of the core,and this method has been used more widely.Would you like to try that?i.e by making disk scheduling we can reduce the time taken to read a file. Implementing disk scheduling in the fs driver seems odd, thus if allocation of sector is done by the kernel then it is possible to perform disk scheduling. As a kernel developer we cannot assume that the driver
regards,
pradeep.