From: jkhasdev@gmail.com (jitendra kumar khasdev)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Modify a file content from block layer
Date: Mon, 22 Oct 2018 22:32:14 +0530 [thread overview]
Message-ID: <CAN-6CVmf-TfsGbto+pUWP=Lyp_Yd-BZCOPu6o2ofofsz0pgZAA@mail.gmail.com> (raw)
In-Reply-To: <244318.1540208329@turing-police.cc.vt.edu>
>
>
> As usual, I'm going to start with:
>
> 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)*
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181022/0f67bd53/attachment.html>
next prev parent reply other threads:[~2018-10-22 17:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 8:26 Modify a file content from block layer jitendra kumar khasdev
2018-10-22 11:12 ` Ozgur
2018-10-22 11:38 ` valdis.kletnieks at vt.edu
2018-10-22 17:02 ` jitendra kumar khasdev [this message]
2018-10-22 18:07 ` valdis.kletnieks at vt.edu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN-6CVmf-TfsGbto+pUWP=Lyp_Yd-BZCOPu6o2ofofsz0pgZAA@mail.gmail.com' \
--to=jkhasdev@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).