I have a ZFS filesystem on an external drive, but the user ID of my accounts don't match between computers. Is there a way to map the UID when mounting (without actually changing it on the filesystem) so that files which are owned by, for example, uid 501, appear as owned by uid 1000? Ideally there's a method that can do this directly, without resorting to bind mounts or overlay filesystems. I've read that linux supports this functionality natively since 5.12 , and that it even should be possible to map IDs in a way that is transparent to the filesystem driver itself, but I can't figure out how to achieve this on the command line. I'm running Fedora 42 with linux kernel version 6.15.4-200 and zfs release 2.3.3-1 from the zfsonlinux.org fedora repository. --- The ID-mapped mount functionality now seems to exist in the mount(8) command as the option **--map-users** _id-mount_:_id-host_:_id-range_. Using an OpenZSH internal option to ignore errors when using the regular "mount" command (as opposed to zfs mount), I've tried:

sudo mount -tzfs -o zfsutil --map-users 1000:501:1 mypool/myfiles /mnt/mypool/myfiles

But this did not seem to map anything.

I'm trying to learn as as much as I can about about the interplay between syscalls, the VFS, device driver handling and ultimately, having the end device do some operation. I thought I would look at a fairly trivial example - creating a file - and try to understand the underlying process in as much detail as possible. I created a bit of C, to do little more than open a (non-existing) file for writing, compiled this (without optimization), and took a peek at it with strace when I ran it. In particular, I wanted to focus on the openat syscall, and why and how this call was ultimately able to not only create the file object / file description, but also actually do the writing to disk (for reference, EXT4 file system, SATA HDD). Broadly speaking, excluding some of the checks and ancilliary bits and pieces, my understanding of the process is as follows (and please correct me if I'm way off!): - ELF is mapped into memory - libc is mapped into memory - fopen is called - libc does its open - openat syscall is called, with the O_CREAT flag among others - Syscall number is put into RAX register - Syscall args (e.g. file path, etc.) are put into RDI register (and RSI, RDX, etc. as appropriate) - Syscall instruction issue, and CPU transition to ring 0 - System_call code pointed to by MSR_LSTAR register invoked - registers pushed to kernel stack - Function pointer from RAX called at offset into sys_call_table - asmlinkage wrapper for the actual openat syscall code is invoked And at that point my understanding is lacking, but ultimately, I know that: 1. The open call returns a file descriptor, which is unique to the process, and maintained globally within the kernel's file descriptor table 2. The FD maps to a file description file object 3. The file object is populated with, among other structures, inode structure, inode_operations, file_operations, etc. 4. The file operations table should map generic syscalls to the respective device drivers to handle the respective calls (such that, for example, when a write syscall is called, the respective driver write call is called instead for the device on which the file resides, e.g. a SCSI driver) 5. This mapping is based on the major/minor numbers for that file/device 6. Somewhere along the line, code is invoked which causes a instructions to be send to the device drive for the hard drive, which gets send to the disk controller, which causes a file to be written to the hard disk, though whether this is via interrupts or DMA, or some other method of I/O I'm not sure 7. Ultimately, the disk controller sends a message back to the kernel to say it's done, and the kernel returns control back to use space. I'm not too good at following the kernel source, though I've tried a little, but feel there's a lot I'm missing. My questions are as follows: I've found some functions which return, and destroy FDs in the kernel source, but can't find where the code is which actually populates the file object / file description for the file. A) On an open or openat syscall, when a new file is created, how is the file structure populated? Where does the data come from? Specifically, how are the file_operations and inode_operations, etc. for that file populated? how does the kernel know, when populating that structure, that the file operations for this particular file need to be that of the SCSI driver, for instance? B) Where in the process - and particularly with reference to the source - does the switch to the device driver happen? For example, if an ioctl or similar was called, I would expect to some reference to the instruction to be called for the respective device, and some memory address for the data to be passed on, but I can't find where that happens. From looking at the kernel source, all I can really find is code that assigns a new FD, but nothing that populates the file structure, no anything that calls the respective file operations to transfer control to a device driver. Apologies that this is a really long-winded description, but I'm really trying to learn as much as possible, and although I have a basic grasp of C, I really struggle to understand others' code. Hoping someone with greater knowledge than I can help clarify some of these things for me, as I seem to have hit a figurative brick wall. Any advice would be greatly appreciated. **Edit:** Hopefully the following points will clarify what technical detail I'm after. - The open or openat syscalls take a file path, and flags (with the latter also being passed an FD pointing to a directory) - When the O_CREAT flag is also passed, the file is 'created' if it doesn't exist - Based on the file path, the kernel is able to identify the device type this file should be - The device type is identified from the major/minor numbers ordinarily - for a file that already exists, these are stored in the inode structure for the file (as member i_rdev) and the stat structure for the file (as members st_dev for the device type of the file system on which the file resides, and st_rdev for the device type of the file itself) So really, my questions are: 1. When a file is created with either of the open syscalls, the respective inode and stat structure must also be created and populated - how do the open syscalls do this (when all they have to go on at this point is the file path, and flags? Do they look at the inode or stat structure of the parent directory, and copy the relevant structure members from this? 2. At which point (i.e. where in the source) does this happen? 3. It's my understanding that when these open syscalls are invoked, it needs to know the device type, in order for the VFS to know what device driver code to invoke. On creating a new file, where the device type has yet to be set in the file object structures, what happens? What code is called? 4. Is the sequence more like: user process tries to open new file -> open('/tmp/foo', O_CREAT) open -> look up structure for '/tmp', get its device type -> get unused FD -> populate inode/stat structure, including setting device type to that of parent -> based on device type, map file operations / inode operations to device driver code -> call device driver code for open syscall -> send appropriate instruction to disk controller to write new file to disk -> tidy up things, do checks, etc. -> return FD to user calling process?

Context: My PC don't boot anymore after a power hard cut. - I can boot a LIVE DVD and mount all file systems. - fsck is clean on my boot partition (ext2) and on my system/root partition (btrfs) - smartctl -t short is clean on both too - I have a legacy BIOS PC (no EUFI) I have reinstalled grub2 from a live DVD and chroot, nothing changed. Here is the error messages provided by the system after the grub splash screen and operating system selection: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-18-amd64 #1 Debian 6.1.76-1 Hardware name: Dell Inc. Studio XPS 8100/0G3HR7, BIOS A05 07/08/2010 Call Trace: dump_stack_lvl+0x44/0x5c panic+0x118/0x2ed mount_block_root+0x1d3/0x1e6 prepare_namespace+0x136/0x165 kernel_init_freeable+0x25c/0x286 ? ret_init+0xd0/0xd0 kernel_init+0x16/0x130 ret_from_fork+0x22/0x30 Kernel Offset: 0x15c00000 from 0xffffffff81000000 (relocatinrange: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- I don't know how to interpret this error message. The root file system is a btrfs one. Shall I understand that the initrd is corrupted and it cannot load the btrfs module required to mount the root FS? What can I do please? Additional information (after having booted on my old kernel): lsblk -e 7 -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ├─sda1 ├─sda2 ├─sda3 77.8G 97% /home └─sda4 sdb ├─sdb1 ├─sdb2 ├─sdb3 115G 45% / └─sdb4 634.2M 29% /boot sdc sdd sde sdf sdg └─sdg1 sr0 _ grep -oP 'root=UUID=[\w-]+' /boot/grub/grub.cfg | sort -u root=UUID=172d2f2b-c176-472b-b20a-0a382e24ae72 This is the right partition for /: /dev/sdb3 cat /etc/fstab UUID=abee2947-6832-4332-915e-abc122a347cf /boot ext2 defaults,noatime 0 2 UUID=172d2f2b-c176-472b-b20a-0a382e24ae72 / btrfs subvol=@,defaults,noatime,space_cache,autodefrag,discard,compress=lzo 0 1 UUID=7994d68f-8067-4742-b104-45ace8e53c0e /home btrfs subvol=/__racine/home,defaults,noatime,nodiratime,space_cache,autodefrag,compress=lzo 0 2 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 UUID=d3529b3b-4338-4371-8f9b-f725142c5eb2 none swap defaults 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,auto 0 0 _ ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 Apr 28 17:32 121C-191D -> ../../sdg1 lrwxrwxrwx 1 root root 10 Apr 28 17:32 172d2f2b-c176-472b-b20a-0a382e24ae72 -> ../../sdb3 lrwxrwxrwx 1 root root 9 Apr 28 17:32 2020-09-26-10-57-36-00 -> ../../sr0 lrwxrwxrwx 1 root root 10 Apr 28 17:32 26a14333-8209-4ae1-bc51-f691d7533e68 -> ../../sda1 lrwxrwxrwx 1 root root 10 Apr 28 17:32 7994d68f-8067-4742-b104-45ace8e53c0e -> ../../sda3 lrwxrwxrwx 1 root root 10 Apr 28 17:32 abee2947-6832-4332-915e-abc122a347cf -> ../../sdb4 lrwxrwxrwx 1 root root 10 Apr 28 17:32 d3529b3b-4338-4371-8f9b-f725142c5eb2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Apr 28 17:32 f530e8e6-9888-4938-8336-f3e4e40565cf -> ../../sdb2 _ ps aux | grep udev root 548 0.0 0.0 23876 6028 ? Ss 17:17 0:00 /lib/systemd/systemd-udevd _ grep error /var/log/syslog 2024-04-28T12:32:15.736464+02:00 PC-Alain kernel: [ 53.465073] nouveau 0000:01:00.0: Direct firmware load for nouveau/nve7_fuc084 failed with error -2 2024-04-28T12:32:15.736468+02:00 PC-Alain kernel: [ 53.465097] nouveau 0000:01:00.0: Direct firmware load for nouveau/nve7_fuc084d failed with error -2 2024-04-28T12:32:41.304635+02:00 PC-Alain kernel: [ 79.156892] nouveau 0000:01:00.0: Direct firmware load for nouveau/nve7_fuc084 failed with error -2 2024-04-28T12:32:41.304641+02:00 PC-Alain kernel: [ 79.156938] nouveau 0000:01:00.0: Direct firmware load for nouveau/nve7_fuc084d failed with error -2 2024-04-28T12:36:54.316202+02:00 PC-Alain wireplumber: RTKit error: org.freedesktop.DBus.Error.AccessDenied 2024-04-28T12:36:54.322518+02:00 PC-Alain pipewire-pulse: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied 2024-04-28T12:36:54.329509+02:00 PC-Alain pipewire: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied 2024-04-28T12:36:54.351221+02:00 PC-Alain wireplumber: RTKit error: org.freedesktop.DBus.Error.AccessDenied 2024-04-28T12:36:54.358502+02:00 PC-Alain pipewire-pulse: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied 2024-04-28T12:36:54.365165+02:00 PC-Alain pipewire: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied 2024-04-28T15:51:21.496580+02:00 PC-Alain kernel: [11999.307831] nouveau 0000:01:00.0: Direct firmware load for nouveau/nve7_fuc084 failed with error -2 2024-04-28T15:51:21.496584+02:00 PC-Alain kernel: [11999.307850] nouveau 0000:01:00.0: Direct firmware load for nouveau/nve7_fuc084d failed with error -2 2024-04-28T16:51:28.020418+02:00 PC-Alain kernel: [15605.817830] traps: tracker-extract trap int3 ip:7f280dd9f7d7 sp:7ffcf0086ab0 error:0 in libglib-2.0.so.0.7400.6[7f280dd61000+8d000] 2024-04-28T16:51:28.268449+02:00 PC-Alain kernel: [15606.063394] traps: tracker-extract trap int3 ip:7f1f488897d7 sp:7ffd77407190 error:0 in libglib-2.0.so.0.7400.6[7f1f4884b000+8d000] 2024-04-28T16:51:47.444575+02:00 PC-Alain dockerd: time="2024-04-28T16:51:47.444485465+02:00" level=info msg="stopping event stream following graceful shutdown" error="" module=libcontainerd namespace=moby _ Here is an extract of my /boot/grub/grub.cfg for the main menu entry: load_video insmod gzio if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi insmod part_gpt insmod ext2 set root='hd1,gpt4' search --no-floppy --fs-uuid --set=root abee2947-6832-4332-915e-abc122a347cf echo 'Loading Linux 6.1.0-18-amd64 ...' linux /vmlinuz-6.1.0-18-amd64 root=/dev/sdb3 ro rootflags=subvol=@ quiet splash } load_video insmod gzio if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi insmod part_gpt insmod ext2 set root='hd1,gpt4' search --no-floppy --fs-uuid --set=root abee2947-6832-4332-915e-abc122a347cf echo 'Loading Linux 6.1.0-18-amd64 ...' linux /vmlinuz-6.1.0-18-amd64 root=/dev/sdb3 ro rootflags=subvol=@ quiet splash }

I'm currently using an i7 with 32 GB of RAM to measure ext4 performance. However, I've encountered some unusual results when testing with 8 GB and 16 GB files. Shouldn't the performance increase instead of decrease? The buffer cache should be taking action and improving the results, not making them worse. In the 16 GB scenario, the file size was 18 GB, and I have no desktop environment; it's solely a testing build. [![Read Report]] [3[![\]]]: " class="img-fluid rounded" style="max-width: 100%; height: auto; margin: 10px 0;" loading="lazy">

The name cache on FreeBSD is responsible for caching file names and their vnodes. It also provides a special database for hashing the contents of large directories. I would like to know how to empty the name cache but I cannot find any tool or sysctl that would allow me to do that. Is it even possible?

I'm reading the Linux kernel implementation of the TCP/IP stack. Everything was ok till I encounter this figure
while reading TCP/IP architecture, design and implementation in Linux As you may see there the author tries to describe the interaction between VFS and the socket layer on Linux. That left me with ton of doubts: On the image it's shown a socket as a part of a file struct under a particular inode, thing is: that relationship doesn't exist anymore! (and tbh doesn't makes a ton of sense since only netlink and unix domain sockets might have inodes associated but not inet sockets isn't it?). See struct file definition; f_dentry dissapeared and while greping you can find > Documentation/filesystems/porting.rst 570: f_dentry is gone; use f_path.dentry, or, better yet, see if you can avoid it Now same struct above does have a reachable dentry (as mentioned in docs) through **f_path** field but **dentry** is described as a two purpose struct, fist for describing a directory entry and second as a file system directory cache, so even if the relationship had not disappeared (as described in picture) this does not make a lot of sense to me, why to put the socket within an object that is intended to be ephemereal, see Dcache (maybe I'm misunderstanding dentry/dcache?). Continuing looking at the code you can see socket struct definition. We can see that it still has the old **file** struct as field (makes more sense to clear VFS -> TCP/IP relationship but conserve TCP/IP -> VFS relationship in those directions for the reason above), but, question is, does it really dissapeared? I'm not seeing anything stopping for fd creation at any kind of socket, see sock_map_fd - sock_alloc_file - alloc_file_pseudo as well. Also this particular **inode** object socket->file->inode) should be existent only in memory since does not pertain to any device filesystem, but, who is its superblock?, see indode.sb . This is not entirely TCP/IP-VFS interaction exactly, but, I can get an inode either from file->f_inode or through file->f_path->d_inode , what is the relation between both inodes?. If someone can help me to understand it would be awesome folks, thanks in advance.

Both plan 9 and FreeBSD have a filesystem-based approach to a unified userspace interface for networking configuration. This paper for example describes the advantages of such an interface, from security to usability, as designed and implemented for FreeBSD. Is there any similar implementation available for linux systems? If not, is there a particular reason this isn't done/doable for linux?

I'm learning Linux procfs, which utilizes a virtual file system where operations like open, read, write, and release are processed by functions registered to it. I've left the open and release to null pointer by mistake, and when I try to read the content of the file, with Python codes like:

with open("/proc/testfile", "r") as f:
    content = f.read()

The program stuck and I read error from the kernel dmesg that null pointer is dereferenced, which is expected, as open is pointed to NULL. However, the cat command from GNU coreutils can do the job, giving me output like

$ cat /proc/testfile
testoutput

which means that cat have not invoked the open function but directly invoking read (write can also be done). In my understanding, open() will return a file descriptor which is further be used to deal with files, and read() requires a file descriptor to continue. How is this be done inside cat?

Linux's Virtual File System(VFS) provides a common interface to multiple file system types, for example, ext2, ext3, VFAT, etc. Imagine an ubuntu host is running several docker containers, and the storage driver of docker is OverlayFS . What's the relation between the ubuntu host's VFS and Docker's OverlayFS? Which tier does OverlayFS belong to? Does it belong to Application, or at the same level as VFS? ## Reference https://unix.stackexchange.com/questions/437285/is-the-virtual-file-system-vfs-a-program-or-is-it-just-an-interface

vmtouch can query cache information about a file's content and load (or even lock) that into cache. Is there a utility which do the same with a file's metadata like dentries and inode information?

I use Linux for a while, now. I always thought that there is only one rootfs in Linux. However, I recently read that PipeFS is mounted in "pipe:", in its own root. How is this possible. Are they separate instances of VFS, or is it just one of its features to manage multiple roots?

I study with details the structure of the VFS superblock and I noticed the field struct hlist_head s_pins; Even though I made an extensive search it was not possible to find info about this. I only found that this is defined and used in fs_pins.c and in functions as pin_insert & etc cetera, but there is no information about its usage and its role. In fact, I found a PIN control subsystem, but I don't know if this is the same since it seems to be associated to hardware pins and not to file systems.

I'm reading the book "Linux Kernel Development", and there are some important points: 1. inode doesn't include filename. 2. filenames are stored in directory entry(dentry). 3. but dentry is not stored on disk, it's dynamic generated. > Unlike the previous two objects, the dentry object does not correspond > to any sort of on-disk data structure.TheVFS creates it on-the-fly > from a string representation of a path name. Because the dentry object is > not physically stored on the disk, no flag in struct dentry specifies > whether the object is modified (that is, whether it is dirty and needs > to be written back to disk). So the question is: where exactly the file names store? and how "list directory" works?

I recently got the following question in a test. Which of the following requests do not go through the Virtual File System (VFS) in Linux? 1. Reading/writing to a Windows partition from Linux 2. Reading the input of a keyboard 3. Sending output to a monitor 4. All of the above go through VFS What should be the answer to this question? PS: This was asked in a 20 minutes quiz.

As per my understanding kernel maintains 4 tables. 1. Per process FD table. 2. System wide open file table struct file 3. Inode (in-memory) table struct vnode 4. Inode (on-disk) table. struct file have one field named struct file_operations f_ops; which contains FS specific operations like ext2_read(), ext2_write(); struct vnode also have one field struct vnodeops v_op; which contains FS specific operations too. My question is why we have similar functionalities inside both? Or am I getting something wrong? Are things different in Unix and Linux? Because I did not find struct vnode inside Linux's fs.h Reference: https://www.usna.edu/Users/cs/wcbrown/courses/IC221/classes/L09/Class.html Diagram (from "Unix internals new frontiers" book)

After reading some articles on the Linux VFS page cache and the tunable parameters like dirty_ratio i was under the impression that page cache would operate as both read and write caching layer. But using the simple test below it works well to improve read speed for files that are located in the page cache but doesn't seem to work on writes. e.g. Clear the cache and write to file. # swapoff -a # echo 3 > /proc/sys/vm/drop_caches # dd if=/dev/zero of=/home/flo/test bs=1M count=30 30+0 records in 30+0 records out 31457280 bytes (31 MB) copied, 0.182474 s, 172 MB/s Check that file is actually in page cache # vmtouch /home/flo/test Files: 1 Directories: 0 Resident Pages: 7680/7680 30M/30M 100% Elapsed: 0.000673 seconds Read from file to confirm is actually coming from cache. # dd if=/home/flo/test of=/dev/null bs=1M count=30 30+0 records in 30+0 records out 31457280 bytes (31 MB) copied, 0.00824169 s, 3.8 GB/s Drop cache and read again to prove speed difference. # echo 3 > /proc/sys/vm/drop_caches # dd if=/home/flo/test of=/dev/null bs=1M count=30 30+0 records in 30+0 records out 31457280 bytes (31 MB) copied, 0.132531 s, 237 MB/s Since i'm not using DIRECT_IO with dd I was expecting the page cache to be used as a writeback type of cache. And based on dirty_ratio or dirty_expire_centiseconds... eventually the data would be committed to disk. Can someone please explain how VFS handles the read and write process differently, especially during writes and why there is no speed gain. Is there any way to make the vfs more aggressive in write caching so it behaves more like the writeback cache you might find on a raid controller for example. Thank you fLo

Sorry about the noob question. I just built the cross compiler, created the filesystem hierarchy, compiled the kernel and BusyBox and put it on a USB and installed GRUB. When I boot it, I get this:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

I would say that I tried to fix it, but I don't even know what the error means, so I don't know how to begin. I searched google and all I found were distro-specific answers. My inittab (not sure if it matters):

::sysinit:/etc/rc.d/startup

tty1::respawn:/sbin/getty 38400 tty1
tty2::respawn:/sbin/getty 38400 tty2
tty3::respawn:/sbin/getty 38400 tty3
tty4::respawn:/sbin/getty 38400 tty4
tty5::respawn:/sbin/getty 38400 tty5
tty6::respawn:/sbin/getty 38400 tty6

::shutdown:/etc/rc.d/shutdown
::ctrlaltdel:/sbin/reboot

My fstab:

# file system  mount-point  type   options          dump  fsck
#                                                         order

rootfs          /               auto    defaults        1      1
proc            /proc           proc    defaults        0      0
sysfs           /sys            sysfs   defaults        0      0
devpts          /dev/pts        devpts  gid=4,mode=620  0      0
tmpfs           /dev/shm        tmpfs   defaults        0      0

Thank you! **Edit: I now get another error after troubleshooting: Kernel panic - not syncing: No working init found. EDIT 2: Now I get the error “Kernel panic - not syncing: Requested init /sbin/init failed (error -2).”**

On Linux, the openat syscall can be used to create files and to test for their existence. Speaking in terms of the C/C++ memory model, creating a file and verifying its existence creates a synchronizes-with relationship. What I need to know is whether these synchronizations are all sequentially-consistent with each other. (I certainly hope so, but I haven't actually seen this documented anywhere.) For example, given processes p1 and p2, and paths A and B: if p1 does this: create(A), then create(B) and p2 does this: try to open(B), then try to open(A) and no other processes interfere with A or B, is it possible for p2 to open B successfully but fail to find A? If it makes a difference, we can assume all operations are within one filesystem.

[~]$ stat -c %i / 2 As you can see in above, the inode for / is 2. But the First inode of /dev/sda2 is 11. [~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 350G 67G 266G 21% / tmpfs 12G 44M 12G 1% /dev/shm [~]$ sudo tune2fs -l /dev/sda2 | grep 'First inode' First inode: 11 Can any one help me to understand this difference?

**Does kernel really create any new inode when some file system gets mounted** on some directory of root file system? I don't expect it to create as there is no new files are being created. Is there some soft link being created? I've read that superblock operation reads field of "newly created inode" from mounted file system.