Block size in block device drivers
ZXNet echo conference «zxnet.soft»
Hello, All
Let's imagine that we want to write an OS for Speccy. :)
You will need block device drivers.
What block size should I use?
Hello, captain cobalt
Within the framework of this issue, the difference between the concepts of sector and block is significant.
For example, iS-DOS uses 1K sectors but 256 byte blocks.
The second aspect is uniformity of support for different drives. If OS will be directly
support only your own format, and the rest only through special copiers -
this is not good.
Hello, captain cobalt
First, how about the simplest solution: block size = sector size.
The file system driver asks the block driver: "what size is your
block?", and decides for himself whether this size is suitable.
Hello, captain cobalt
cap> Within the framework of this issue, the difference between the concepts of sector and block
cap> is essential. For example, iS-DOS uses 1K sectors but 256 byte blocks.
Then we need to decide on the terminology.
In CP/M, the minimum block for the OS is called a logical sector and has the size
128 bytes.
Hello, captain cobalt
cap> What block size should I use?
Most often you have to focus on the maximum possible size
physical block (sector).
If we talk about CP/M, for example, then it is rational to choose the block size equal to 1
kbyte.
Hello, captain cobalt
I propose a Windows-like driver hierarchy. :D
The device driver (FDD,HDD,CD-ROM,RAMDISK...) receives from the upstream
file system driver information about the desired BLOCK size. If the driver
devices cannot support the required block size - that’s it, the life of this file
The system with this device driver did not work out. If he can, everything is fine.
Thus, for the TR-DOS file system, a block size of 256 bytes will be requested, for FAT - 512
bytes, etc. Problems with block-sector conversion are completely taken care of
device driver.
As an option, we can propose an even more complex scheme -
"device driver" - "driver-converter" - "FS driver".
The device driver tells the converter the sector size that supports
device The FS driver tells the converter the block size. And the converter is busy
transformation of passing information - dividing blocks into sectors and
gluing.
In both cases, uniformity of support for different FS on different
device True, difficulties arise in the details (such as if you are asked to write down a block
256 bytes on a device with 512 byte sectors, you will have to read the whole thing first
sector, replace the desired block in it and write it back), but I think that all this
solvable.
Hello, captain cobalt
cap> Let's imagine that we want to write an OS for Speccy.
:) :) :)
Just imagine, you have a floppy disk with a format of kilobytes per sector. pzuhoy by
Normally, you will not read only a quarter of the sector to get 256 bytes.
you will have to read the entire sector into a temporary buffer, and then retrieve it from
him right where he needs it...
maybe it would be easier for the person who works with the device to decide whether he can use it
Is this how to work? and let him work in his own way :) maybe this one will be even better for him
kilobyte, than first you will break it, and then it will come back...
i.e., IMHO, everything depends on the sector size :) and unnecessary (not justified?) virtualization
only eat fast food...
Hello, psb
use the block size that is more convenient (easier) for organizing the file
systems. There is no need to complicate things. And, in essence, what's the difference? If you can
work with any sector size, then you can add a utility to work with
other formats. To once again transfer data from TRDOS to normal
file system and forget about it forever like a nightmare. :) Yes, to
for example, the CP/M format already implemented on the ZX (on the issue of bicycles) -
implemented for any block size in exactly the described way - read NNN
bytes (physical sector), of which NN bytes (logical sector) are allocated. And,
by the way, with log. sector 128byte and physical 512/1k in good form in versions
BIOS CP/M was able to read as much as 2k into the buffer at a time :), which significantly speeded up
the average statistical process (on linear reading in particular) of working with the HGMD.
This is to keep it simple. And if you want adventure, then immediately plan modularity
file system, where, with a common API, it is possible to connect modules of different
file systems, and what they will do inside themselves is purely their personal
matter.
By the way, most file systems have already been written and exist in open source.
Here, for example, is a version adapted for microcontrollers (by code size)
for FAT12/16/32, you only need to customize the procedures for working with sectors - and
all:
http://elm-chan.org/fsw/ff/00index_e.html
Hello Alex Crush
Taxi... Stop!
We talk about the block size in block device drivers, or the size
block in virtual FS drivers?
When it comes to block device drivers, the block size is ALWAYS equal to
media block size. If you rise to the FS level, then the block size will be
correspond to the block size adopted for this FS. And the recalculation of these blocks
carried out by a virtual driver, which is precisely the
a mechanism that "smoothes out" all differences for the file system API.
Hello jdigreze
Pointless discussion. IMHO, the user should be given the opportunity to choose
FS block size, regardless of sector size. jdigreeze is right.
Hello, captain cobalt
jdi> Tax... Stop!
jdi> We are talking about the block size in block device drivers, or
jdi> block size in virtual FS drivers?
We're talking about a software interface between block drivers and drivers
file systems.
When a file system driver uses routines like blockRead and
blockWrite, what size blocks should be transferred?
Hello, captain cobalt
In this case, the block size must be equal to the file system block size,
accepted as the main one. The remaining FS must be connected via
virtual drivers, which level out the difference in block sizes and
structure of FS information.
Hello, captain cobalt
This is too narrow and a proprietary solution, when a flexible one is much simpler.
Are there any suggestions for choosing the main FS?
Hello, captain cobalt
Well, probably NTFS... Although no, ReiserFS will be more reliable... ;) A joke of humor!
Of all the systems, I have not seen one that would satisfy all the essential
needs. I think the FS from iSDOS is closest to the norm, but it’s not ideal either,
especially in terms of disk space usage on hard drives.
There are some sketches for its modernization through virtualization of the mechanism
work with drives, which should not affect at least the existing
application software of this system. But work on this has so far come to a standstill because of my
employment. If possible, write to me, I will definitely answer.
Hello Alex/AT
> Are there any suggestions for choosing the main FS?
Transactional FAT. If you are perverted, you can use ext2, but there will be overhead
not weak...
Hello jdigreze
> When the file system driver uses routines like blockRead and
> blockWrite, what size blocks should be transferred?
The file system itself determines the block size and works with LBA block numbers. All
other differences are leveled out by the block driver and cache. How formatted
disk - not so important here.