61. Linux Filesystem(EXT4, XFS, BTRFS), Logical Volume Manager(LVM), Logical Volume, Increasing space inside a VM, Creating a new logical Volume, Increasing the existing LV Storage - Agnivo102/Database_Architect GitHub Wiki
So all the data we save are all on the physical hard drive (just on a piece of silicon and billions of microscopic mathematic circuit drawn on them). The operating system need to map every data we keep in an organised way or it wont be able to find the data when required. Like we need to organize our things in a organized way to find them when required. This organising things inside the memory is the job of Filesystem.
Now Linux mainly uses 3 file system.
This system is like a standard library system. Imagine a library with 1000s of books, how will anyone organize it. First there will an index. All the books will be organises in shelves, and the location of all books (i, e this book is places on bookshelve number 24, slot number 76, serial number 123 etc), all these details is saved on the index. The entire library structure is planned from the start. Like architects pre draw the entire design
like bookshelf 34 is entirely for history books, this bookshelve 77 for physics books, bookshelve 22 if for literature books and bookshelf 22's slot number 6 is for mystery genre books.
All these things are pre designed so that the librarian will know very quickly where to find this book.
This is basically the ext4 file system about, simple, predictable and a well structured design. This is the standard filesystem for most Linux.
This filesystem is what most enterprises grade Linux distributions use like Oracle Linux. With ext4, as everything is pre planned, if suddenly a huge file like 10 TB is put on the memory, the OS wont be able to properly organize it, simply put it somewhat less flexible. So enterprise grade Linux distribution like Oracle Linux uses xfs filesystem.
This is like a highly active and dynamic warehouse. Imagine, in a standard library where everything is pre organized and predictable, a warehouse is highly Dynamic and changeable. There the designer and manager has to be highly adaptable. If suddenly a huge amount of materials come to tbe warehouse, they have allocate more space to it. This is what xfs filesystem does.
-
Remember we talked about indexes, in ext4 every index is planned from the creation. So it can run out. When the oracle database or any similar heavy weight application runs, it creates many temporary logs of files, and the librarian or the manager has to hand the file a index entry. In ext4 the index can run out and it can't create more as everything is preplanned. So even if many physical memory is left the OS can't create more files stopping the application. But in xfs the index will never run out as everything is highly dynamic. So it can handle heavy weight applications.
-
Parallel processing. There are multiple cpu cores which can handle complex mathematics parallely by itself, the parallel processing. But in case of ext4, every bookshelve exist in the same logical area, so different CPU core or different librarians can sometimes get in each other's way. In xfs the warehouse is divided into many different logical area's each section has different managers or CPU cores called Allocation Groups, so this increases the speed significantly which helps running heavy weight applications.
-
Third is trees. Both ext4 and xfs uses trees or a mathematical map to arrange the data in the physical memory. Without that it wont be able to find the specific data stored it there. This is similar to a dictionary where is every word is sorted and the library. Ext4's tree is like this:
Index number, and a small description of the data in it and the location of the physical circuit there data is at. When a file comes, the OS put it to a hashing algorithm or in simple words a mathematices formula and turning the filename into a random looking hash number. The mathematical map of the data is organised based on this hash number.
Comparisson with real world: Imagine a librarian who takes a book title, runs it through a secret mathematical formula, and gets a random locker number (e.g., 4829). The book is placed in locker 4829.
This emebles really first searching, as the user gives the file name, OS calculates the hash and immediately goes to that location. The con is this that because the files are placed based on unsorted. To be clear it is sorted based on the mathematical hash numbers, but it creates problem for heavy weight application, because it can't keep related files close to each other.
Again comparisson with real world: Imagine 3 related book is in 4829, 1092, 012, if the application wants to read them, then the librarian has to move back and forth which waste a huge amount of time.
For xfs uses B+ trees for everthing, directories, free space tracking, and file data chunks:
B+ Tree: Index number and the location of the physical circuit there data is at. This one is sorted alphabatically by filename, or sequentially by block address.
When a heavy application or database runs, it rarely asks for just one random file. It frequently does range queries or sequential reads—for example: "Give me all transaction logs from ID 1000 to ID 2000" or "Read all files belonging to this folder in order." This is much easier with XFS B+ trees. Also as oracle database follows similar naming convention, their physical location are also close to each other with XFS, this helps in performance.
A combination of all of these factors make xfs file system much more suited for enterprises grade Linux distributions.
This is somewhat different from both ext4 and xfs. Btrfs is a an extremely secure system with a undo button and huge quality control.
It mainly has 4 things:
In case of ext4 and xfs when user is updating a file, the worker goes to the selve or inode holding the file, erases the old things, the put the new things there. There is a danger to that. If power goes out while a file is currently being updated then half of the old data will remain and half of data will be there making the file corrupted.
Btrfs uses a feature called copy on write. What happens is that when an user updates the file, the worker is forbidden to touch its inodes, it goes to an empty brand new shelfe or inode and writes the new data there. After the data writting is finished 100% the file pointer in index will finally point to the new inode and old inode is marked as empty. This saves data from corruption if a modification was going on during power outage. There is also twist there. There are 2 modes:
Normal mode: In normal mode if we update a file, as we said the new file will be written on a different inode, after it is completed, it will uodate the master index to point at the bew inode, then the old inode will ve marked as empty and the old data is deleted.
Snapshot mode or time machine index: In snapshot mode, after the workers has finished writting rhe new file after a modification and updated the master index to point to the new shelve, the old inode will not be deleted because a snapshot, as its namesake will freeze the old file too. Master index will not delete the old file as the snapshot still points to it. So an update will take double the space. But this is also helpful to keep the old version of the file.
This is what the snapshot feature enables. If an update breaks the system or you accidentally deletes a folder, you can instantly reverts back to time of the snapshot was taken and the folder will be back.
Evertime a new file arrives btrfs calculates a checksum(the file is processed in a mathematical formula and a string of number or hash number is generated, if the data in the file is altered anyway then the hash number will be changed from before, by this we can know if the file is altered from the original or not), and puts it in a separate b tree. When an user asks for a file, btrfs checks the checksum of the current file with the one in its index, if during moving or any other way the data is corrupted or changed, then the hash number will not match and the btrfs throws an error. If the same data is present in multiple places and one of them is not changed the it will hand the unchanged one.
Qvolume in place of volume group and sub volume in place of Logical volume, slightly different from logical volume, where different logical volume have different master index, all sub volume have same master index, the wall between them is flexible, we can limit any application or user by creating a small room or quota which mathematically forbids them from adding more data in their space then what we said, but this volume os flexible, if the OS needs that space as the others are full it can press that space of that sub volume if necessary.
This different /dev/mapper/ol-root and /dev/mapper/ol-home are not allocation groups. These are Logical volumne.
A logical volume is logical divition that divides the physical memory into various parts. LVM (Logical volume manager, the part of OS which manages the LVs) comnines all the physical space into a signle pool of memory. From that pool, we can slice out different Logical partitions, resize them according to our requirement. Example of this is
/dev/mapper/ol-root point to / and is used by the Oracle Linux OS itself and the Oracle application, /dev/mapper/ol-home points to /home/ and is ued for keeping all the user personal files,
The reason for doing this is: In case of enterprise grade applications like linux, every second the database runs it writes logs in the memory, imagine without this logical partition it wrote so many logs or temporary files that it fills up the space required by the OS to run causing the entire system to crash. For that with the partition the logs will only be wrtten in the partition assigned to the application and if the space gets filled up it will only cause problem for the logging process instead of crashing the entire thing which lets us to login to fix the issue.
Also logical volume lets us use separate filesystem in different partitions if want.
We can also scale the storage independed to each other, we want the database to have more storage for its data files, without giving more space for the users partiton.
devmpfs: A temporary filesystem managed by th OSe kernel that holds device nodes (like hardware drivers and internal device files) in RAM.
tmpfs / /dev/shm: A temporary filesystem that uses the computer's RAM for high-speed inter-process communication like the database bg processes like ckpt and dbwn will use this LV for communication.
tmpfs / /run: A temporary filesystem used by the system to store runtime state data and process IDs while the system is running. Remember in Linux everything has a process id we can see trough top, ps -f etc. All those porocess ids is stored there. It lives in the RAM
tmpfs / /sys/fs/cgroup: A control group filesystem used by the kernel to manage and limit resource usage (CPU, memory, I/O) for system processes. if there is no limit for system processes when one process can stop other processes from working crashing the system. So this is used by the OS to manage the processes. It also lives in the RAM.
/dev/sda1: A standard physical boot partition mapped to /boot. It holds the Linux kernel and bootloader files required to start up the system. Without this the system can't start up.
tmpfs / /run/user/54321 (356M): A temporary runtime directory created specifically for user ID 54321 (which is typically the default user account for the oracle database installation, the oracle user).
These 3 tmpfs / /run/user/54321, tmpfs / /sys/fs/cgroup, tmpfs / /run these 3 LVs live in the RAM not on the secondary memory.
This would be like, / is the main root directory which holds everything inside it both /u01 and others. Currently the OS and the oracle application is using /dev/mapper/ol-root LV. So if the application takes the whole space then the OS will crash as it needs a space to run. So if we create a new LV inside the /dev/mapper/ol-root LV (it will like a small room inside a big room, the user in small room will be limited to the small room only and can't touch the outside bigger room which the main user the OS is using) the application will not choke the OS.
Now we won't confuse between Logical Volumes and Allocation groups. LVM or logical volume manager manager and divide the memory into high level partitions, Allocation groups are mini or small partitions inside a LV. We can't see this, the OS does this to fully manage and use the storage and resources like in a department there will be multiple small manager working separately but intercommunicating.
This is same for ext4, xfs and btrfs. When someone cut paste a file, the actual file is not moved to a new inode, just it updates master index and points to the new location. In case of copy and paste, the ext4 just duplicates the file, but btrfs and xfs just creates a second entry in the master index, taking 0 seconds and 0 extra space.but btrfs and xfs just creates a second entry in the master index, taking 0 seconds and 0 extra space (even if you change the file owner and permission in the copied version, the permission all these are metadata exist in the master index, only the second master index permission will be change, but they still will point to the same physical inode). Only if you cut and paste it to a different Logical volume then the data has to be moved physically to a different space, that is what in case of xfs and ext4 as different LV has different master indexes. In case of btrfs subvolumes its subvolumes all share a single master index. So there data has not be moved physically and one master index update is enough. In case of deletion in case of btrfs, it keeps track how many pointers keep pointing to that inode. So in normal mode upon deleting the counter drops to 0 and the space goes back to the OS. In case of snapshot, the counter will not drop to 0 so the space will not be free to the OS and only if the snapshot is deleted the space will be free.
VG Name: ol: This is the name of the Volume Group (the total giant storage pool).
Cur LV: 3: It currently have 3 active Logical Volumes carved out of this pool (which correspond to root, home, and swap partitions).
Cur PV: 1: There is 1 Physical Volume (1 physical hard drive or virtual disk partition) feeding into this storage pool.
VG Size: <59.00 GiB: The total storage capacity of the entire pool is about 59 GB.
Alloc PE / Size: 15102 / 58.99 GiB: It has allocated almost the entire pool—58.99 GiB out of 59 GiB is already being used by the current logical volumes.
Free PE / Size: 1 / 4.00 MiB: It only have 4 MB of free space left in the entire pool!
Step 2: We can either shrink any LV and add here or add new space. Lets shrink the users LV. Run umount /home to unmount the home partition, and make sure you are not logged in in the partition.
e2fsck -f /dev/mapper/ol-home
This error because e2fsck is for checking the ext4 file system while the home LV has xfs file system, we checked it with blkid /dev/mapper/ol-home.
Now as it is xfs we can't shrink it down. The reason for that is XFS was designed for enterprise grade applications and it is desgned for going up, not going down or shrinking.
To shrink a filesystem, it have to move all data sitting at the very end of the drive to a safer, earlier spot, and then chop off the physical blocks at the tail end.
Because XFS spreads its metadata, inodes, and file extents dynamically across multiple Allocation Groupss from the beginning to the end of the partition, cleanly "slicing off" a chunk at the end without corrupting an AG is extremely complex and risky.
Lets try the 2nd option which is to add new disk.
First step give more space to the VM. First turn off the VM, then follow the steps. Go to settings then storage. Then click on controller sata and add hard disk. Then a new window opens up, and click on create, then add the storage you want to add and its location, the click on finish. The add the newly created disk inside the VM by double clicking it.
Step 2: When you add a new disk in VirtualBox while the VM is running, Linux doesn't automatically use it. You first need to see what name Linux gave it. First detect the new hard drive using command lsblk.
See the new disk we added 15 GB is there named as sdb or storage device b.
Step 3: Before LVM can use a raw disk, you have to stamp it as an official "Physical Volume" (PV) so LVM knows it's allowed to touch it.
command: pvcreate /dev/sdb
This formats the raw disk /dev/sdb with LVM metadata headers, turning it into a building block that LVM can recognize and control.
Step 4: Remember the main volume group ol. That's the master warehouse pool. If you want LVM to access the new space, you have to dump it into that pool.
command: vgextend ol /dev/sdb
Extends the Volume Group named ol by absorbing the new physical volume (/dev/sdc). This increases your total available storage pool size (e.g., from 59 GB to 74 GB).
Step 5: Now that your master pool is bigger, you can slice out a brand-new "room" (Logical Volume) for a specific project, application, or mount point.
Example Command: lvcreate -n new_LV_Name -l 10G ol
Command: lvcreate -n test -L 1G ol
-n test: Names the new Logical Volume (so its path will become /dev/ol/test).
-L 1G: Allocates a specific size of 1 Gigabytes out of the ol pool. (Alternatively, you could use -l +100%FREE to grab all remaining space).
ol: Specifies which Volume Group pool to carve the space out of.
LVM has built the room walls, but it doesn't have filing cabinets yet. You have to build the shelves and the entire system or filesystem inside it.
mkfs.xfs /dev/ol/text
mkdir /test mount /dev/ol/test /test
Now a new LV is created and the space inside the /test directory will be separate from the others inside the test LV.
. lsblk . pvcreate /dev/sdb . pvs (optional to verify the newly created Physical Volume) . vgs, vgdisplay (for gettings details about volume groups) . vgextend ol /dev/sdb OR vgcreate new /dev/sdb (We can also create a brand new volume group) . lvcreate -n new -L 2G ol . mkfs.xfs /dev/ol/new(for xfs)/mkfs.ext4 /dev/ol/new(for ext4) . mkdir /new, mount /dev/ol/new /new
command: pvcreate /dev/sdb
Step 4: Again use the command: vgextend ol /dev/sdb to add the new physical volume inside the volume group ol.
lvextend -L +14G /dev/ol/root
-L +14G: Tells LVM to grab 14 GB newly available free space in the pool.
/dev/ol/root: Specifies which logical volume room is getting bigger.
LVM physically expands the boundaries of the ol-root block device.
LVM made the room bigger, but the XFS filing system inside doesn't automatically know about it until you tell it.
Command: xfs_growfs /
See with df -h that it has increased.
. lsblk . pvcreate /dev/sdb . pvs (optional to verify the newly created Physical Volume) . vgs, vgdisplay (for gettings details about volume groups) . vgextend ol /dev/sdb OR vgcreate new /dev/sdb (We can also create a brand new volume group) . lvextend -L +14G /dev/ol/root (Increase the ol-root LV storage by 14 GB)/ lvextend -L +100%FREE /dev/ol/root (Increase the ol-root LV storage by all the available space in the ol volume group) . xfs_growfs / (tells the XFS that space has increased and it can be used) . df -h (validate the increased space)