Modify a file content from block layer

[jitendra kumar khasdev]

Hi All,

Is there any way, by which I could write/update the sectors of a file
(which already exist or created in user space) from the block layer
interfaces?

---
Jitendra

[Ozgur]

_______________________________________________
Kernelnewbies mailing list
***@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[v***@vt.edu]

Post by jitendra kumar khasdev
Is there any way, by which I could write/update the sectors of a file
(which already exist or created in user space) from the block layer
interfaces?

As usual, I'm going to start with:

Step 0: What problem are you trying to solve by doing this?

The problem is that the kernel shouldn't be scribbling on files itself, and
that's *extremely* discouraged. The gory details of why basically boil down
to "the VFS assumes that all filesytem scribbling is called from a user process
context", which causes all sorts of problems if you're in a non-user process
context, or a non-process context entirely.

The only two in-kernel uses of this that I know of are the acct() system call
and the disk quota system - and the case can be made that for the limited case
of disk quotas, the file system should do the work.

And BSD accounting dates back to before Linux, and when Linux sprouted an
acct() system call, there was a good reason to work the same way as the BSD/
SYSV version did it - and even more importantly, it happened *way* before
netlink interfaces happened. If we were re-doing it today, netlink would be a
slam dunk.

Ponder the fact that the kernel is up to over 15M lines of code, and there's only
two in-tree users that scribble on files from inside the kernel. If it was a good idea,
we'd probably have more examples of it...

In general, you'll have a *much* easier time of it if you avoid writing files
from within the kernel - see as an alternate design the kernel printk() buffer
and the way that dmesg/syslog reads it out to userspace, or the ways that perf
gets its data out to userspace.

(There's also deep philosophical issues if you're over-writing blocks of a user
created file, because users have a very reasonable expectation that if they
write a given piece of data into a file system, they get the exact same data
back when they read it...)

[jitendra kumar khasdev]

Post by v***@vt.edu
Step 0: What problem are you trying to solve by doing this?

Working on a custom driver that tracks I/Os on block level. For some use
case, I need to write metadata of tracked I/Os from driver in shutdown
sequence (more likely in reboot handler). In reboot handler, performing I/O
on disk is tricky (no userspace, no VFS. no sysfs).
Although, I am able to write one sector, by creating custom bio and giving
manually sector to disk. Still, looking some correct API like
*write_IO_on_disk(buffer,
dev, offset, len)*

Post by v***@vt.edu
The problem is that the kernel shouldn't be scribbling on files itself, and
that's *extremely* discouraged. The gory details of why basically boil down
to "the VFS assumes that all filesytem scribbling is called from a user process
context", which causes all sorts of problems if you're in a non-user process
context, or a non-process context entirely.

I understand it. Ideally, best practices, I should be not do that, but here
is custom scenario, in which in reboot handler no VFS APIs will be
accessible.

(There's also deep philosophical issues if you're over-writing blocks of a

Post by v***@vt.edu
user
created file, because users have a very reasonable expectation that if they
write a given piece of data into a file system, they get the exact same data
back when they read it...)

But kernel developer should have an interface which takes only buffer, and
write on a particular sector, even though it discouraged, but having that
facility would not harm.
---
Jitendra

[v***@vt.edu]

Post by jitendra kumar khasdev
Working on a custom driver that tracks I/Os on block level. For some use
case, I need to write metadata of tracked I/Os from driver in shutdown
sequence (more likely in reboot handler). In reboot handler, performing I/O
on disk is tricky (no userspace, no VFS. no sysfs).

Now take a step back.

What problem are you trying to solve by scribbling on blocks? What's in the
metadata that (a) needs to be preserved and (b) can't be done by feeding it
to a userspace process?

Hint: A number of dm targets need to track I/Os and manage to do so without
writing to a file system.

Post by jitendra kumar khasdev
Although, I am able to write one sector, by creating custom bio and giving
manually sector to disk. Still, looking some correct API like
*write_IO_on_disk(buffer, dev, offset, len)*

That's just *looking* for an fsck. :)