LinuxQuestions.org
Register a domain and help support LQ
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 08-22-2013, 02:42 PM   #1
gacanepa
Member
 
Registered: May 2012
Location: San Luis, Argentina
Distribution: Debian
Posts: 203

Rep: Reputation: 26
/etc/fstab options: dev / nodev, sync/async


Hi everyone,
After going through a lot of tutorials, I still find it difficult to understand the 2 options of /etc/fstab mentioned in the title of this thread.
From what I've read about dev / nodev is that you don't want people to be able to create block devices in a regular filesystem. Actually, even if someone manages to do it, the nodev option will tell the filesystem to not treat the block device as such, but as a regular file. Am I right? If not, please feel free to correct me. Also, why is this a way of hardening a system? (meaning I've seen this same thing in other places always related to security).
As to the sync / async options, I don't see why someone would want that save, delete, move operations be performed later instead of when one of those commands is run affecting files in a filesystem configured as async.
Any ideas / corrections will be more than welcome. Thanks in advance!
 
Old 08-22-2013, 04:00 PM   #2
MensaWater
LQ Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 6,580
Blog Entries: 14

Rep: Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969
block "devices" are used to interact with your hardware. Imagine if someone created block device that had the same major/minor as say /dev/sda. They'd could be able to corrupt the hard drive at /dev/sda without doing direct write to /dev/sda because it is the major/minor that tell it where the physical hardware is rather than just the device name. (This is one reason why your /dev/sda on one boot might become say /dev/sdc on another boot if you had 3 hard drives.)

As to the synchronization the stuff the simple answer is performance. If your application THINKS it has written the data then it moves on to its next task. The big downside to doing this is that if your system crashes before the data is actually committed to disk by background processes then it goes away with everything else that is in memory. It's a choice of speed vs. integrity. On an extremely reliable system you might opt for the speed because you don't expect it to have issues very often.
 
1 members found this post helpful.
Old 08-22-2013, 06:13 PM   #3
gacanepa
Member
 
Registered: May 2012
Location: San Luis, Argentina
Distribution: Debian
Posts: 203

Original Poster
Rep: Reputation: 26
Quote:
Originally Posted by MensaWater View Post
block "devices" are used to interact with your hardware. Imagine if someone created block device that had the same major/minor as say /dev/sda. They'd could be able to corrupt the hard drive at /dev/sda without doing direct write to /dev/sda because it is the major/minor that tell it where the physical hardware is rather than just the device name. (This is one reason why your /dev/sda on one boot might become say /dev/sdc on another boot if you had 3 hard drives.)

As to the synchronization the stuff the simple answer is performance. If your application THINKS it has written the data then it moves on to its next task. The big downside to doing this is that if your system crashes before the data is actually committed to disk by background processes then it goes away with everything else that is in memory. It's a choice of speed vs. integrity. On an extremely reliable system you might opt for the speed because you don't expect it to have issues very often.
Thanks for your answer!
I hope you don't mind one more question. What do you mean by major/minor? I believe I understand the rest of your answer, but that detail is not 100% clear to me.
 
Old 08-22-2013, 06:22 PM   #4
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 7,183

Rep: Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212
Every such device is identified by a pair of numbers, referred to as the "major" and "minor" device-numbers, respectively.
 
1 members found this post helpful.
Old 08-22-2013, 10:01 PM   #5
gacanepa
Member
 
Registered: May 2012
Location: San Luis, Argentina
Distribution: Debian
Posts: 203

Original Poster
Rep: Reputation: 26
Thanks guys, I got it.
Now I understand what the 5th field in the output of
Code:
ls -l /dev
means. It turns out it's the major/minor numbers of the device.
I will mark this thread as solved and add to your reputation. Thanks again!

(Just for the record in case someone needs it in the future, these are 2 great links to learn what the major/minor numbers are: The Linux Tutorial and The Geek Stuff)

Last edited by gacanepa; 08-22-2013 at 10:09 PM.
 
Old 08-23-2013, 03:41 PM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,604

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
Quote:
Originally Posted by sundialsvcs View Post
Every such device is identified by a pair of numbers, referred to as the "major" and "minor" device-numbers, respectively.
Well... mostly. The major/minor numbers ORIGINALLY represented two index values into a table.

The major number is the index/subscript into a device driver table. The minor number is the index/subscript into a unit table with the the device driver table.

In the current Linux system, these numbers are actually not used much. The /dev directory is a memory resident filesystem that has entries created when controllers/devices are identified. This allows a faster access to the device by allowing the memory resident structure (not reflected in the major/minor numbers) to have direct links to the referenced data structure that used to be done using the major/minor numbers. Using the major/minor indexing requires two operations - first verify that the major index is valid (identifying the driver), use that to identify the minor list(the unit within that driver), then verify the minor index is valid, then use the result to perform the I/O operation. The direct link is either null (no such device) or valid - reducing the overhead significantly.

The other reason for not using the major/minor numbers is storage. The inode used to hold these values is a 32 bit value (originally 16 bits), so spliting that 32 bits up is a bit tricky - some controllers may use 12 bits to identify the major (driver), leaving 20 bits for the minor (unit)... This is the current default. Problems will occur when more than 4096 drivers exist at a time. One reason it is tricky is disks - the minor number is split up into two parts: one to identify the disk drive (the actual unit), and the other to identify the partition. The problem is how to identify the bits needed for each part...

Current kernels use devtmpfs (a derivitive of devfs, but is managed entirely within the kernel).

A little follow up - you can identify what drivers the major number is associated with, they are listed in the file /proc/devices. There are two sets - one for character devices, one for block devices (so the major number could be for either one, and seeing a given number in a /dev entry, you also have to look to see if it is a block or character device reference...)

You can see the block device table (with minor references) in the file /proc/partitions. This lists the major/minor number along with the size and current device name.

I say "current" here, because the name can change on each boot (as can the major/minor number for that matter). This is because the kernel assigns these values during device initialization. Devices that get added later get the next available number, but if you have 3 disks (sda/sdb/sdc), and the physical device sdb is not plugged in at boot, then the devices get named sda/sdb - and the physical disk FORMERLY identified as sdc becomes sdb...

This is why using device names in the /etc/fstab file is depreciated - use the UUID or volume name. These values are assigned when the partition is initialized, and are static as the system will read these values during initialization, which makes them available during the rest of the system initialization (specifically, when the system uses the /etc/fstab file to mount the partitions).

Last edited by jpollard; 08-23-2013 at 03:51 PM.
 
  


Reply

Tags
dev, fstab, sync


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 to re-sync disks (/dev/sdc1, /dev/sdc3, etc) FireRaven Linux - Newbie 1 09-30-2010 01:45 AM
'nodev' and 'nodev' option for removable media wjs1990 Linux - Newbie 1 01-06-2010 03:58 AM
No 'sync' or 'async' option specified for export ":". cccc Linux - Networking 2 05-31-2007 06:31 PM
want to mount removable disk as async not sync tkalfaoglu Linux - Software 3 02-10-2006 07:34 AM
sync and async serial of Routers whepin General 0 11-06-2002 08:38 PM


All times are GMT -5. The time now is 01:22 AM.

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