How to extend the filesystem size in CentOS (default is XFS) running as a VMware guest?

sudo fdisk /dev/sdc –> /dev/sdc1

Then issue "pvcreate /dev/sdc1".

This will add the disk to the physical volume group (pvdisplay), noticed the "VG name" is not assigned yet:

vgextend centos /dev/sdc1 —> after this the following 59.5 G is displayed.

And "sudo pvdisplay" will show that /dev/sdc1 is assigned to the VG group "centos".

But lvdisplay still showing old values:

Finally, "lvextend -l +100%FREE /dev/centos/root" and this will extend the VG extents to the 57G limit.

Finally, boot in rescue mode and do the following (this is for ext4 filesystem):

resize2fs /dev/mapper/centos-root

But if your filesystem is XFS, which is default for CentOS 7.2 1511:

The rootfs is running XFS, and XFS does allow online resizing.

So without any rebooting or rescue mode:

So now the rootfs have been properly resize by the command:

xfs_growfs -d /dev/mapper/centos-root

The option "-d" is for maximum possible size.

So in summary, for LVM only the last part is different between XFS and ext4 filesystem: resize2fs or xfs_growfs command.

How does KCOVtrace worked (in the Linux Kernel)?

We all are familiar with how strace worked: it uses the system call “ptrace” to attach to a process and then setting breakpoints on all the system call.

So how does KCOVTRACE worked?

The tool is available here:

https://github.com/google/syzkaller/blob/master/tools/kcovtrace/kcovtrace.c

It requires the kernel to be compiled with CONFIG_KCOV.

When applied on a binary like “/bin/ls” and let it execute, we get a list of addresses as output:

0xffffffff81a109e4
0xffffffff81a109da
0xffffffff81a109e4
0xffffffff81a109da
0xffffffff81a109e4

To know the address 0xffffffff81a109e4, let use the Linux kernel image file “vmlinux”, do a disassembly via “objdump -d vmlinux”:

As we can see the address is the byte offset immediately following calling the function <__sanitizer_cov_trace_pc>.

This function is inserted using GCC plugin mechanism when the linux kernel is compiled with GCC plugin enabled, and CONFIG_KCOV=y.

Inside kernel/kcov.c, you see that that the address of each basic block that got executed in the kernel is updated into “area[]” array, which get floats to the userspace, which is retrieved via /sys/kernel/debug/kcov interface ioctl() read.

Extracted from above URL and displayed as below:

Since only the process that explicitly open the /sys/kernel/debug/kcov interface will get to receive the output the kcov is therefore specific to the process that open the file descriptor.

(unlike FTRACE, where the interface can be open, and another process generate FTRACE in the kernel, only to be retrieve by final process that read the FTRACE).

Having fun with funcgraph, functrace, and funccount

The utility tool "funcgraph" is a script that is based on "FTRACE", and in Ubuntu it is available through the following packages.

apt-file search funcgraph

perf-tools-unstable: /usr/bin/funcgraph
perf-tools-unstable: /usr/share/doc/perf-tools-unstable/examples/funcgraph_example.txt.gz

And looking at all the binaries inside perf-tools-unstable:

First trying to understand kmem_cache_alloc calls (execute via "sudo" as root privilege is needed):

(sudo funcgraph -m 100 "kmem_cache_alloc")

or understanding "scheduler":

(funcgraph -m 100 "schedule*")

Or trying to understand ext4* calls:

(funcgraph -m 100 "ext4*")

And then there is the "functrace" calls:

functrace ‘tcp*’

The command "funccount -t 10 ‘tcp*’" cannot be generated as my kernel lacks the kernel configuration:

And then there is tpoint:

References:

http://www.brendangregg.com/Slides/LISA2014_LinuxPerfAnalysisNewTools.pdf