LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 01-13-2015, 06:12 PM   #1
david_8274
Member
 
Registered: Jun 2013
Location: California
Distribution: Ubuntu, Fedora
Posts: 74

Rep: Reputation: Disabled
What are the differences between character devices and block devices?


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
 
Old 01-13-2015, 07:03 PM   #2
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,599

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
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.

Last edited by jpollard; 01-13-2015 at 07:20 PM.
 
1 members found this post helpful.
Old 01-13-2015, 07:20 PM   #3
david_8274
Member
 
Registered: Jun 2013
Location: California
Distribution: Ubuntu, Fedora
Posts: 74

Original Poster
Rep: Reputation: Disabled
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
 
Old 01-13-2015, 07:39 PM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,599

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
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.
Old 01-13-2015, 07:48 PM   #5
david_8274
Member
 
Registered: Jun 2013
Location: California
Distribution: Ubuntu, Fedora
Posts: 74

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
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.


Thank you for the detailed explanation!
Wei
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How do I map ATA devices to /dev/sd* block devices when using a port multiplier? Mahonri Linux - Hardware 0 02-20-2014 12:44 AM
Registering character devices... mohit.saha Linux - Newbie 3 08-09-2013 03:10 AM
iSCSI Targets for Tape (character) Devices ben.kuiper Linux - Networking 3 03-15-2007 11:18 AM
what is the different btw raw devices and block devices yenonn Linux - General 2 02-10-2006 10:34 PM


All times are GMT -5. The time now is 08:34 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration