What is LVM and does it required on Linux servers?
LVM is a logical volume manager. It requires to resize filesystem size. This size can be extended and reduced using lvextend and lvreduce commands respectively. You can think of LVM as dynamic partitions, meaning that you can create/resize/delete LVM partitions from the command line while your Linux system is running: no need to reboot the system to make the kernel aware of the newly-created or resized partitions. LVM also provides:
You can extend over more than one disk if you have more than one hard-disk. They are not limited by the size of one single disk, rather by the total aggregate size.
You can create a (read-only) snapshot of any LV (Logical Volume). You can revert the original LV to the snapshot at a later time, or delete the snapshot if you no longer need it. This is handy for server backups for instance (you cannot stop all your applications from writing, so you create a snapshot and backup the snapshot LV), but can also be used to provide a "safety net" before a critical system upgrade (clone the root partition, upgrade, revert if something went wrong).
you can also set up writeable snapshots too. It allows you to freeze an existing Logical Volume in time, at any moment, even while the system is running. You can continue to use the original volume normally, but the snapshot volume appears to be an image of the original, frozen in time at the moment you created it. You can use this to get a consistent filesystem image to back up, without shutting down the system. You can also use it to save the state of the system, so that you can later return to that state if you mess things up. You can even mount the snapshot volume and make changes to it, without affecting the original.
12) What is umask and how can it be helpful on linux server?
When user create a file or directory under Linux or UNIX, it created with a default set of permissions. In most case, the system defaults may be open or relaxed for file sharing purpose. The user file-creation mode mask (umask) is used to determine the file permission for newly created files. It can be used to control the default file permission for new files.
It acts as a set of permissions that applications cannot set on files. It's a file mode creation mask for processes and cannot be set for directories itself. Most applications would not create files with execute permissions set, so they would have a default of 666, which is then modified by the umask.
As you have set the umask to remove the read/write bits for the owner and the read bits for others, a default such as 777 in applications would result in the file permissions being 133. This would mean that you (and others) could execute the file, and others would be able to write to it.
If you want to make files not be read/write/execute by anyone but the owner, you should use a umask like 077 to turn off those permissions for the group & others.
The default umask on Ubuntu is 0022 which means that newly created files are readable by everyone, but only writable by the owner:
# umask
0022
# touch file
# ls -l
total 3340
-rw-r--r-- 1 root root 3412144 Nov 20 17:26 coreutils-8.22-18.el7.x86_64.rpm
-rw-r--r-- 1 root root 0 Apr 7 04:00 file
# umask 133
# umask
0133
# touch new-file
# ls -l
total 3336
-rw-r--r-- 1 root root 3412144 Nov 20 17:26 coreutils-8.22-18.el7.x86_64.rpm
-rw-r--r-- 1 root root 0 Apr 7 04:00 file
-rw-r--r-- 1 root root 0 Apr 7 04:00 new-file
13) There is two command to schedule automated task, why should I use cron instead of anacron? What is the difference between the two?
When we schedule task in cron jobs, we have the possibility to use cron and anacron. But there is a frequently asked question which should be and what are the particularity of the two commands?
Both cron and anacron are daemons that can schedule execution of recurring tasks to a certain point in time defined by the user. The main difference between cron and anacron is that the former assumes that the system is running continuously. If your system is off and you have a job scheduled during this time, the job never gets executed.
On the other hand anacron is 'anachronistic' and is designed for systems that are not running 24x7. For it to work anacron uses time-stamped files to find out when the last time its commands were executed. It also maintains a file /etc/anacrontab just like cron does. In addition, cron.daily runs anacron everyhour. Also, anacron can only run a job once a day, but cron can run as often as every minute so
cron gives minimum granularity in minute while Anacron gives it in days
Cron job can be scheduled by any normal user while Anacron can be scheduled only by the super user (the superuser is a special user account used for system administration.
Cron expects the system to be up and running while the Anacron doesn’t expect the system to be up and running all the time. In case of Anacron, if a job is scheduled and the system is down that time, it will execute the job as soon as the system is up and running so cron is ideal for servers while anacron is ideal for desktops and laptops.
cron should be used when you want a job to be executed at a particular hour and minute while Anacron should be used in when the job can be executed irrespective of the hour and minute.
14) What is an inode?
File systems, in general, have two parts: the metadata or the “data” about the data and the data itself. Metadata consist of information about the data. More precisely it includes information such as the Access Control List (ACL), the date the file was modified, file owner, file permissions, size of file, device ID, uid of the file, etc. This type of information is key to a file system otherwise we just have a bunch of bits on the storage media that don’t mean much. Inodes store this metadata information and typically they also store information about where the data is located on the storage media.
In a file system, inodes consist roughly of 1% of the total disk space, whether it is a whole storage unit (hard disk, thumb drive, etc.) or a partition on a storage unit. The inode space is used to track the files stored on the hard disk. The inode entries only points to these structures rather than storing the data. Each entry is 128 bytes in size.Space for Inodes is allocated when the operating system or a new file system is installed and when it does its initial structuring. So this way we can see that in a file system, the aximum number of Inodes and hence maximum number of files are set. Now, the above concept brings up another interesting fact. A file system can run out of space in two ways:
No space for adding new data is left
All the Inodes are consumed.
To get a listing of an inode number, use ls -i command.
ls -li
total 3336
57741 -rw-r--r-- 1 root root 3412144 Nov 20 17:26 coreutils-8.22-18.el7.x86_64.rpm
57725 -rw-r--r-- 1 root root 0 Apr 7 04:00 file
57736 -rw-r--r-- 1 root root 0 Apr 7 04:00 new-file
# ls -li new-file
57736 -rw-r--r-- 1 root root 0 Apr 7 04:00 new-file
# find /root -inum 57736
/root/new-file
15) When you get a "filesystem is full" error, but 'df' shows there is free space, what is the problem?
It is possible that we have free storage space but still we cannot add any new data in file system because all the Inodes are consumed. the df -i command will show that. This may happen in a case where file system contains very large number of very small sized files. This will consume all the Inodes and though there would be free space from a Hard-disk-drive point of view but from file system point of view no Inode available to store any new file.
A storage unit can contain numerous small files. Each file takes up 128 bytes of the inode structure. If the inode structure fills up before the data storage of the disk, no more files can be copied to the disk. Once inode storage is freed in the structure, the storage unit can have files written to it again.
# touch test-file
touch: cannot touch 'test': no space left on device
# df -Th
Filesystem Type Size Used Avail Use% Mounted onFilesystem
udev devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs tmpfs 788M 10M 778M 2% /run
/dev/sda6 ext4 44G 24G 18G 59% /
/dev/sda7 ext4 103G 74G 24.0G 71% /home
/dev/sda2 vfat 95M 29M 67M 31% /boot/efi
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 1002898 650 1002248 1% /dev
tmpfs 1008079 1128 1006951 1% /run
/dev/sda6 2875392 617635 2257757 22% /
/dev/sda7 6815744 80342 6735402 100% /home
LVM is a logical volume manager. It requires to resize filesystem size. This size can be extended and reduced using lvextend and lvreduce commands respectively. You can think of LVM as dynamic partitions, meaning that you can create/resize/delete LVM partitions from the command line while your Linux system is running: no need to reboot the system to make the kernel aware of the newly-created or resized partitions. LVM also provides:
You can extend over more than one disk if you have more than one hard-disk. They are not limited by the size of one single disk, rather by the total aggregate size.
You can create a (read-only) snapshot of any LV (Logical Volume). You can revert the original LV to the snapshot at a later time, or delete the snapshot if you no longer need it. This is handy for server backups for instance (you cannot stop all your applications from writing, so you create a snapshot and backup the snapshot LV), but can also be used to provide a "safety net" before a critical system upgrade (clone the root partition, upgrade, revert if something went wrong).
you can also set up writeable snapshots too. It allows you to freeze an existing Logical Volume in time, at any moment, even while the system is running. You can continue to use the original volume normally, but the snapshot volume appears to be an image of the original, frozen in time at the moment you created it. You can use this to get a consistent filesystem image to back up, without shutting down the system. You can also use it to save the state of the system, so that you can later return to that state if you mess things up. You can even mount the snapshot volume and make changes to it, without affecting the original.
12) What is umask and how can it be helpful on linux server?
When user create a file or directory under Linux or UNIX, it created with a default set of permissions. In most case, the system defaults may be open or relaxed for file sharing purpose. The user file-creation mode mask (umask) is used to determine the file permission for newly created files. It can be used to control the default file permission for new files.
It acts as a set of permissions that applications cannot set on files. It's a file mode creation mask for processes and cannot be set for directories itself. Most applications would not create files with execute permissions set, so they would have a default of 666, which is then modified by the umask.
As you have set the umask to remove the read/write bits for the owner and the read bits for others, a default such as 777 in applications would result in the file permissions being 133. This would mean that you (and others) could execute the file, and others would be able to write to it.
If you want to make files not be read/write/execute by anyone but the owner, you should use a umask like 077 to turn off those permissions for the group & others.
The default umask on Ubuntu is 0022 which means that newly created files are readable by everyone, but only writable by the owner:
# umask
0022
# touch file
# ls -l
total 3340
-rw-r--r-- 1 root root 3412144 Nov 20 17:26 coreutils-8.22-18.el7.x86_64.rpm
-rw-r--r-- 1 root root 0 Apr 7 04:00 file
# umask 133
# umask
0133
# touch new-file
# ls -l
total 3336
-rw-r--r-- 1 root root 3412144 Nov 20 17:26 coreutils-8.22-18.el7.x86_64.rpm
-rw-r--r-- 1 root root 0 Apr 7 04:00 file
-rw-r--r-- 1 root root 0 Apr 7 04:00 new-file
13) There is two command to schedule automated task, why should I use cron instead of anacron? What is the difference between the two?
When we schedule task in cron jobs, we have the possibility to use cron and anacron. But there is a frequently asked question which should be and what are the particularity of the two commands?
Both cron and anacron are daemons that can schedule execution of recurring tasks to a certain point in time defined by the user. The main difference between cron and anacron is that the former assumes that the system is running continuously. If your system is off and you have a job scheduled during this time, the job never gets executed.
On the other hand anacron is 'anachronistic' and is designed for systems that are not running 24x7. For it to work anacron uses time-stamped files to find out when the last time its commands were executed. It also maintains a file /etc/anacrontab just like cron does. In addition, cron.daily runs anacron everyhour. Also, anacron can only run a job once a day, but cron can run as often as every minute so
cron gives minimum granularity in minute while Anacron gives it in days
Cron job can be scheduled by any normal user while Anacron can be scheduled only by the super user (the superuser is a special user account used for system administration.
Cron expects the system to be up and running while the Anacron doesn’t expect the system to be up and running all the time. In case of Anacron, if a job is scheduled and the system is down that time, it will execute the job as soon as the system is up and running so cron is ideal for servers while anacron is ideal for desktops and laptops.
cron should be used when you want a job to be executed at a particular hour and minute while Anacron should be used in when the job can be executed irrespective of the hour and minute.
14) What is an inode?
File systems, in general, have two parts: the metadata or the “data” about the data and the data itself. Metadata consist of information about the data. More precisely it includes information such as the Access Control List (ACL), the date the file was modified, file owner, file permissions, size of file, device ID, uid of the file, etc. This type of information is key to a file system otherwise we just have a bunch of bits on the storage media that don’t mean much. Inodes store this metadata information and typically they also store information about where the data is located on the storage media.
In a file system, inodes consist roughly of 1% of the total disk space, whether it is a whole storage unit (hard disk, thumb drive, etc.) or a partition on a storage unit. The inode space is used to track the files stored on the hard disk. The inode entries only points to these structures rather than storing the data. Each entry is 128 bytes in size.Space for Inodes is allocated when the operating system or a new file system is installed and when it does its initial structuring. So this way we can see that in a file system, the aximum number of Inodes and hence maximum number of files are set. Now, the above concept brings up another interesting fact. A file system can run out of space in two ways:
No space for adding new data is left
All the Inodes are consumed.
To get a listing of an inode number, use ls -i command.
ls -li
total 3336
57741 -rw-r--r-- 1 root root 3412144 Nov 20 17:26 coreutils-8.22-18.el7.x86_64.rpm
57725 -rw-r--r-- 1 root root 0 Apr 7 04:00 file
57736 -rw-r--r-- 1 root root 0 Apr 7 04:00 new-file
# ls -li new-file
57736 -rw-r--r-- 1 root root 0 Apr 7 04:00 new-file
# find /root -inum 57736
/root/new-file
15) When you get a "filesystem is full" error, but 'df' shows there is free space, what is the problem?
It is possible that we have free storage space but still we cannot add any new data in file system because all the Inodes are consumed. the df -i command will show that. This may happen in a case where file system contains very large number of very small sized files. This will consume all the Inodes and though there would be free space from a Hard-disk-drive point of view but from file system point of view no Inode available to store any new file.
A storage unit can contain numerous small files. Each file takes up 128 bytes of the inode structure. If the inode structure fills up before the data storage of the disk, no more files can be copied to the disk. Once inode storage is freed in the structure, the storage unit can have files written to it again.
# touch test-file
touch: cannot touch 'test': no space left on device
# df -Th
Filesystem Type Size Used Avail Use% Mounted onFilesystem
udev devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs tmpfs 788M 10M 778M 2% /run
/dev/sda6 ext4 44G 24G 18G 59% /
/dev/sda7 ext4 103G 74G 24.0G 71% /home
/dev/sda2 vfat 95M 29M 67M 31% /boot/efi
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 1002898 650 1002248 1% /dev
tmpfs 1008079 1128 1006951 1% /run
/dev/sda6 2875392 617635 2257757 22% /
/dev/sda7 6815744 80342 6735402 100% /home
0 Comments
Post a Comment