<div dir="ltr">Thanks Arshad, Luis for the response.<br>This project was on back burner for a while and now it's<br>coming back to life.<br><br>tl;dr: I'm looking for a way to tell if a given inode object<br>belongs to a persistent block device or not ex: a sysfs node<br>doesn't have a corresponding block device backing it.<br><br>I looked into the source code for hdparm implementation.<br>I was able to borrow a lot of it and move them in kernel (for<br>academic purposes only). Here's my (very limited) understanding so<br>far, hdparm tries to read a storage device's 'geometry' which includes<br>info such as cylinders, heads, sectors etc. on mechanical disks. One<br>of the key parameters of a storage device is the start_lba which is<br>basically the first block on a persistent device that contains data<br>from a given file. In hdparm, it is able to get this info by simply<br>reading from the block device's sysfs node, under,<br>/sys/dev/block/.../start<br>I intend to do something similar in the kernel by doing something<br>similar to when the above sysfs node is read. The implementation for<br>this is partition-generic.c<br>However, I need to run this for each and every read system call which<br>includes all the procfs, sysfs and other RAM fs based file reads. My<br>code is causing the kernel to panic at some point due to an illegal<br>memory access while trying to obtain the starting sector/block for the<br>file that's currently being read. My hunch is the crash occurs when<br>file being read is on a non-persistent fs such as a sysfs node<br>I have gotten hold of the inode structure and I'm trying to find if<br>a given inode is stored persistently or not and I've been unable to<br>find this information so far. I have all the appropriate NULL checks<br>and each time it crashes the accessed address points a garbage,<br>non-zero address. Any thoughts or inputs are highly<br>appreciated. Thanks.<br><br><br>--<div class="gmail_default" style="font-family:monospace,monospace;display:inline">Manoj</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 27, 2016 at 8:32 PM, arshad hussain <span dir="ltr"><<a href="mailto:arshad.super@gmail.com" target="_blank">arshad.super@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Thu, Apr 28, 2016 at 7:28 AM, Manoj Rao <<a href="mailto:linux@manojrajarao.com" target="_blank">linux@manojrajarao.com</a>> wrote:<br>
> Hi All,<br>
><br>
> I'm looking for a way to get a filename associated with a given physical<br>
> block (ideally what I'd like is a mapping of filename <=> all the allocated<br>
> blocks for this file).<br>
<br>
</span>If you have not done already, this could be a good starting point.<br>
Look at FIBMAP IOCTL.<br>
<br>
Here is one usage of FIEMAP, demonstrated via hdparam.<br>
# hdparm --fibmap <your file name><br>
<span><br>
><br>
> Is there a recommended way to do this already in kernel? if not, then where<br>
> should I start looking to add changes?<br>
<br>
</span>Not sure about what would be the Recommended method. But this could be done<br>
in user-space vs doing it in kernel space. For example, consider cases like<br>
single file restore - there will be a requirement to figure out the<br>
logical - physical block allocation for a file which could be achieved<br>
through...<br>
Read superblock<br>
Read dentry - Home into the required inode (file)<br>
Read inode - to figure out the location of block.<br>
<br>
Note: This is not generic - and would require changes as layout is different<br>
for filesystems.<br>
<br>
Thanks<br>
<span><font color="#888888">Arshad<br>
</font></span></blockquote></div><br></div></div>