I have a module that is cresting debugfs entries in /sys/kernel/debug/example .
But i didnt see those files in sysfs/kernel/example directory.
I see this function which do the debugfs entry creations are called in late_initcall.
late_initcall(example_debug_init);
Will this late_initcall affect the entry creation?
Sounds like you have not mount debugfs. Do it by:
mount -t debugfs none /sys/kernel/debug
For more information about using debugfs, read debugfs.txt in kernel Documentation.
Also you must enable the:
CONFIG_DEBUG_FS=y
configuration at build time, or else mount will fail.
Here is a minimal example: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/bb8f4eb79565c9771356c80e0964c8fefc163e11
Related
Getting "Input / output error" when trying work with files in mounted HDFS NFS Gateway. This is despite having set dfs.namenode.accesstime.precision=3600000 in Ambari. For example, doing something like...
$ hdfs dfs -cat /hdfs/path/to/some/tsv/file | sed -e "s/$NULL_WITH_TAB/$TAB/g" | hadoop fs -put -f - /hdfs/path/to/some/tsv/file
$ echo -e "Lines containing null (expect zero): $(grep -c "\tnull\t" /nfs/hdfs/path/to/some/tsv/file)"
when trying to remove nulls from a tsv then inspect for nulls in that tsv based on the NFS location throws the error, but I am seeing it in many other places (again, already have dfs.namenode.accesstime.precision=3600000). Anyone have any ideas why this may be happening or debugging suggestions? Can anyone explain what exactly "access time" is in this context?
From discussion on the apache hadoop mailing list:
I think access time refers to the POSIX atime attribute for files, the “time of last access” as described here for instance (https://www.unixtutorial.org/atime-ctime-mtime-in-unix-filesystems). While HDFS keeps a correct modification time (mtime), which is important, easy and cheap, it only keeps a very low-resolution sense of last access time, which is less important, and expensive to monitor and record, as described here (https://issues.apache.org/jira/browse/HADOOP-1869) and here (https://superuser.com/questions/464290/why-is-cat-not-changing-the-access-time).
However, to have a conforming NFS api, you must present atime, and so the HDFS NFS implementation does. But first you have to configure it on. [...] many sites have been advised to turn it off entirely by setting it to zero, to improve HDFS overall performance. See for example here ( https://community.hortonworks.com/articles/43861/scaling-the-hdfs-namenode-part-4-avoiding-performa.html, section "Don’t let Reads become Writes”). So if your site has turned off atime in HDFS, you will need to turn it back on to fully enable NFS. Alternatively, you can maintain optimum efficiency by mounting NFS with the “noatime” option, as described in the document you reference.
[...] check under /var/log, eg with find /var/log -name ‘*nfs3*’ -print
I test whether a file is empty in Shell.
test -s /sys/fs/cgroup/systemd/docker/d4e311735706485e748513bad611070e223cba76fdf4c72a1102d14b653da750/tasks
It returns false, and I found its size is 0 when I use ls -lh, but when I use cat, I can get 4071 in this file, this means the file is not empty. I think maybe this file is too small, I create a file in my home directory, and echo 4071 to it, I find its size is not 0. Is the file in /sys/fs/cgroup special?
The file that you are dealing with is a special file which is a part of the cgroup file system.
To understand why this happens, let's see what happens when you do test -e $filename.
We will be using strace command which prints the system calls a command does.
If you do strace test -e $filename, you will find this line in the results:
stat("$filename", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
In this case it returns st_size = 0 which is the size of the file.
But the questions is what actually happens on the other side, inside the kernel:
When you try to deal with a file, you do a system call which goes to an intermediate layer in the kernel called the virtual file system which in turn calls the part responsible for the information needed. A stat system call will try to get the status out of the inode corresponding with file. The file system can create and manipulate the inode as it wants.
Cgroup is a special file system, when it adds a file (using the cgroup_add_file function defined in kernel/cgroup.c) it always passes size 0 to __kernfs_create_file so that is why any file inside /sys/fs/cgroups (created by cgroup fs) will always has a zero size regardless of the actual contents of the file.
For the other part, when cat the file. If you do strace cat $filename, that is what you will get:
open("$filename", O_RDONLY) = 3
read(3, "...", 131072) = ###
The read system call will go through the virtual file system to the kernel file system and using the file operations associated with the file, it will get you the needed data.
Cgroup fs has functions to generate the data in its files. This is how tasks file is defined in kernel/cgroup.c
{
.name = "tasks",
.seq_start = cgroup_pidlist_start,
.seq_next = cgroup_pidlist_next,
.seq_stop = cgroup_pidlist_stop,
.seq_show = cgroup_pidlist_show,
.private = CGROUP_FILE_TASKS,
.write = cgroup_tasks_write,
},
So seq_start, seq_next, seq_stop and seq_show are the functions responsible for generating the information needed for the file. You can easily go to kernel/cgroups.c and check for what they do.
Please note that if you are trying to know if the cgroup still has tasks, an easier way is to use notify on release.
from Documentation/cgroup-v1/cgroups.txt
If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup is removed, then the kernel runs the command specified by the contents of the "release_agent" file in that hierarchy's root directory, supplying the pathname (relative to the mount point of the cgroup file system) of the abandoned cgroup. This enables automatic removal of abandoned cgroups. The default value of notify_on_release in the root cgroup at system boot is disabled (0). The default value of other cgroups at creation is the current value of their parents' notify_on_release settings. The default value of a cgroup hierarchy's release_agent path is empty.
I have some question about Linux kernel and GPIOs. I know that in Linux everything is file so when I do something like
echo 30 > /sys/class/gpio/export
and
echo 1 > /sys/class/gpio/gpio30/value
what really happens? I mean how does sysfs handle that? Does it call system calls implemented in gpiolib?
The gpiolib registers the value attribute in this way:
static const DEVICE_ATTR(value, 0644, gpio_value_show, gpio_value_store);
It creates a device attribute named value, with permission 644; on read it calls gpio_value_show, on write it calls gpio_value_store
What sysfs does, is to redirect read and write to the correspondent function of a sysfs attribute.
On debugging linux kernel 3.6.11 with - "ddd vmlinux /proc/kcore" , the "file_systems" list present in fs/filesystems.c is shown empty, containing the address 0x0 .
It is supposed to contain file_system_type structures of all the registered file systems .
Why the list is empty or where else can I see the list of registered file systems ?
Debugging the kernel is not needed for that. There is a proc API that provides the information:
cat /proc/filesystems
I'm attempting to create a fs within a file.
under linux it's very simple:
create a blank file size 8 gb
dd of=fsFile bs=1 count=0 seek=8G
"format" the drive:
mkfs.ext2 fsFile
works great.
however under cygwin running from /usr/sbin ./mkfs.ext2
has all kinds of weird errors (i assume because of some abstraction)
But with cygwin i get:
mkfs.ext2: Device size reported to be zero. Invalid partition specified, or
partition table wasn't reread after running fdisk, due to
a modified partition being busy and in use. You may need to reboot
to re-read your partition table.
or even worse (if i try to access a file through /cygdrive/...
mkfs.ext2: Bad file descriptor while trying to determine filesystem size
:(
please help,
Thanks
Well it seems that the way to solve it is to not use any path on the file you wish to modify.
doing that seems to have solved it.
also it seems that my 8 gig file does have a file size that's simply to big, it seems like it resets the size var i.e.
$ /usr/sbin/fsck.ext2 -f testFile8GiG
e2fsck 1.41.12 (17-May-2010)
The filesystem size (according to the superblock) is 2097152 blocks
The physical size of the device is 0 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
testFile8GiG: 122/524288 files (61.5% non-contiguous), 253313/2097152 blocks
Thanks anyway