Hi,

I am trying to understand the difference between char devices and block devices.
I understand the basic, which is that char devices input/output data one character at a time, whereas block device input/output data block by block. But for char device driver, most of the time we are able to read/write an array of data using the read/write system call. This "array of data" sounds like a block of data to me, except that it's not fixed in size as for block devices. With this thinking, can I say that I can effectively achieve block read/write with a char device driver?
And what are the other differences?

Thank you all,
Wei

Basically, none. The intent is to provide the optimum access for a device.

Disk devices (including flash) tend to perform best by reading and writing on their native boundaries - thus block access provides better utuilization of system buffers (only one physical read for a block). Think about having to read two blocks from disk, then discard part of one block, and part of the second, and returning the data that spans the two... A bit slow, with multiple I/O. It gets worse when you are writing. Two write you need to first read both blocks, then replace the data that spans, then write both blocks back (total of four I/O operations - especially when the blocks may be scattered, because you now need the seek operations in between).

Character access of some devices work best (terminal, tape, network even) as they don't have a native block nature. Using a character interface to a block device tends to cause multiple I/O operations when it isn't on a block boundary.

The actual difference is more in how the device is treated.

There is less of a difference in Linux than there used to be as many of the features of character devices are also in the block devices - and both access interface may be provided by the same functions.

Some dated references are http://www.linuxjournal.com/article/2890

The answer to your question is "yes". You can do block access with a character device - but there may be a bit more overhead in use, and it will depend on the device. Some devices (such as a terminal) will not allow you to do block type I/O - there may be delays in data, plus you can't seek either backward or forward (it doesn't make any sense...).

UNIX systems also have a designation that the character device interface bypasses the system buffers - which imposes a rather large overhead depending on what you are doing. This is useful if you are doing filesystem repair or debugging, but can cause massive corruption if the block access is ALSO being used.

1 members found this post helpful.

Hi jpollard,

Thank you so much for your reply.
I want to take one step further to MTD devices(such as NAND flash) for embedded system. Based on my understanding, MTD device is neither a conventional char or block device. It seems like Linux's MTD subsystem provides a 'char' driver and a 'block' driver to simulate MTD devices as char devices and block devices. If it's correct, why the MTD subsystem implements this way? (For consistency?)

Thank you,
Wei

Partly consistency, partly it is how the chips work.

The chips themselves have a limited number of pins - thus using them in a semi-block mode reduces the number of pins needed.

This lessened by the flash controller, which can translate between byte and block style of access. One thing the controller provides is a usage leveling that spreads writes out over the entire chip. Thus overwriting a specific block doesn't really overwrite it - you get a block that hasn't been used in a while that is available, and that block is then mapped to the original block location, and the original block is now put on a free list for reuse sometime in the future. This minimizes overwrites (which are the bane of flash chips), and spreads the load. It also improves the general response as without it the block would first have to be erased before it could be overwritten. The blocks on the free list will get erased, but that delay is no longer imposed on the write operation (which goes to an already erased block).

Since there is no seek delay, it doesn't matter that blocks are not contiguous. It does introduce a bit of work on the controller chip when a stream read operation is done, but it is fast enough that it isn't noticeable.

I THINK (not sure as I haven't worked on the chips themselves) there are actually three lists involved - used blocks, free blocks that are erased, and free blocks that need erasing. As long as the chip has power, it will be erasing free blocks to put them on the free list that have been erased. The used list may actually be something like an AVL tree keyed from block address. Thus writing to a block following one already written will just add a new entry in the tree in the appropriate location.

But it will be up to the controller to implement whatever functions are needed for the device.

1 members found this post helpful.

Thank you for the detailed explanation!
Wei