* Modify a file content from block layer @ 2018-10-22 8:26 jitendra kumar khasdev 2018-10-22 11:12 ` Ozgur 2018-10-22 11:38 ` valdis.kletnieks at vt.edu 0 siblings, 2 replies; 5+ messages in thread From: jitendra kumar khasdev @ 2018-10-22 8:26 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181022/26438983/attachment.html> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Modify a file content from block layer 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 1 sibling, 0 replies; 5+ messages in thread From: Ozgur @ 2018-10-22 11:12 UTC (permalink / raw) To: kernelnewbies An HTML attachment was scrubbed... URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181022/f13c4ec8/attachment.html> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Modify a file content from block layer 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 1 sibling, 1 reply; 5+ messages in thread From: valdis.kletnieks at vt.edu @ 2018-10-22 11:38 UTC (permalink / raw) To: kernelnewbies On Mon, 22 Oct 2018 13:56:27 +0530, jitendra kumar khasdev said: > 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...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181022/4d128232/attachment.sig> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Modify a file content from block layer 2018-10-22 11:38 ` valdis.kletnieks at vt.edu @ 2018-10-22 17:02 ` jitendra kumar khasdev 2018-10-22 18:07 ` valdis.kletnieks at vt.edu 0 siblings, 1 reply; 5+ messages in thread From: jitendra kumar khasdev @ 2018-10-22 17:02 UTC (permalink / raw) To: kernelnewbies > > > 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> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Modify a file content from block layer 2018-10-22 17:02 ` jitendra kumar khasdev @ 2018-10-22 18:07 ` valdis.kletnieks at vt.edu 0 siblings, 0 replies; 5+ messages in thread From: valdis.kletnieks at vt.edu @ 2018-10-22 18:07 UTC (permalink / raw) To: kernelnewbies On Mon, 22 Oct 2018 22:32:14 +0530, jitendra kumar khasdev said: > 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. > 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. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181022/19a00d3b/attachment.sig> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-10-22 18:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2018-10-22 18:07 ` valdis.kletnieks at vt.edu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.