On Thu, Sep 11, 2008 at 8:48 PM, Paulo da Silva <psdasilva@xxxxxxxxxxxx> wrote: > Peter Teoh escreveu: >> >> I don't really understand the meaning of "will die". >> > > So don't I. > ... > >> so when bd_inode "will die", does it mean that the inode will become >> non-available? > > Well ... I thought the element "bd_inode" will be removed from the device > structure. But it is heavily used! "mapping" is used in lots of page > manipulation functions, and the only way I found to reach the address space > (mapping) of a device is using bd_inode! For example btrfs, in development, > uses it. > So I must be wrong and "will die" shall mean anything else. I would not think too much about such a comment - as it is too brief to be meaningful. But conceptually, it is impt to know that the physical device upon which the block device is connected can be disconnected (ie, "will die"). As the following URL: http://readlist.com/lists/vger.kernel.org/linux-kernel/28/141859.html (which describe a physical pullout of the IDE, while still mounted?) Second concept is that this bd_inode is to create the object in the buffer cache to buffer the data for the physical device - this is where address space mapping comes in. To answer your question, so when the physical device is not connected, i think it is pointless to get the address space mapping. Am I correct? Eg, in mm/filemap.c, the pagecache flushing mechanism will attempt writing, but when error in writing to block device occurred (eg, the functions pagecache_write_end() and file_direct_write() for direct I/O etc) it will be returned as one of the error condition (eg, EIO). Correct? -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
