On Thu, Jan 20, 2011 at 12:10:14PM +0800, Andrew Morton wrote:
On Thu, 20 Jan 2011 11:21:49 +0800 Shaohua Li [off-list ref] wrote:
quoted
quoted
It seems to return a single offset/length tuple which refers to the
btrfs metadata "file", with the intent that this tuple later be fed
into a btrfs-specific readahead ioctl.
I can see how this might be used with say fatfs or ext3 where all
metadata resides within the blockdev address_space. But how is a
filesytem which keeps its metadata in multiple address_spaces supposed
to use this interface?
Oh, this looks like a big problem, thanks for letting me know such
filesystems. is it possible specific filesystem mapping multiple
address_space ranges to a virtual big ranges? the new ioctls handle the
mapping.
I'm not sure what you mean by that.
ext2, minix and probably others create an address_space for each
directory. Heaven knows what xfs does (for example).
quoted
If the issue can't be solved, we can only add the metadata readahead for
specific implementation like my initial post instead of a generic
interface.
Well. One approach would be for the kernel to report the names of all
presently-cached files. And for each file, report the offsets of all
the pages which are presently in pagecache. This all gets put into a
database.
At cold-boot time we open all those files and read the relevant files.
To optimise that further, userspace would need to use fibmap to work
out the LBA(s) of each page, and then read the pages in an optimised order.
To optimise that even further, userspace would need to find the on-disk
locations all the metadata for each file, generate the metadata->data
dependencies and then incorporate that into the reading order.
I actually wrote code to do all this. Gad, it was ten years ago. I
forget how it works, but I do recall that it pioneered the technology
12 more quoted lines
There are much smarter ways of doing this of course, especially with
the vfs data structures which we later added.
Yup :) The attached patch walks sb->s_inodes and dumps a ordered view
of all cached file pages. It will list each cached files and pages in
the order of the struct inode create time.
The patch will record and show the command name that first opened the
file. (At the time we dump the page cache, the task may no longer
exists.) Although the field is very useful in some cases, it does add
runtime overheads. I'm not sure how to balance this situation. Adding
a compile time option? But then the trace output becomes dependent on
kernel configuration, which may confuse user space tools (at least the
dumb ones).
Otherwise the patch is good enough for wider review.
Here is a trimmed example output.
root@bay /home/wfg# echo / > /debug/tracing/objects/mm/pages/dump-fs
root@bay /home/wfg# cat /debug/tracing/trace
The output are made of intermixed lines for inode and page. The
corresponding field names are:
file lines:
ino size cached age(ms) dirty type first-opened-by file-name
page lines:
index len page-flags count mapcount
1507329 4096 8192 309042 ____ DIR swapper /
0 2 ____RU_____ 1 0
1786836 12288 40960 309026 ____ DIR swapper /sbin
0 10 ___ARU_____ 1 0
1786946 37312 40960 309024 ____ REG swapper /sbin/init
0 6 M__ARU_____ 2 1
6 1 M__A_U_____ 2 1
7 1 M__ARU_____ 2 1
8 2 _____U_____ 1 0
1507464 4 4096 309022 ____ LNK swapper /lib64
0 1 ___ARU_____ 1 0185 more lines
<googles>
According to http://kerneltrap.org/node/2157 it sped up cold boot by
"10%", whatever that means. Seems that I wasn't sufficiently impressed
by that and got distracted.
I'm not sure any of that was very useful, really. A full-on coldboot
optimiser really wants visibility into every disk block which need to
be read, and then mechanisms to tell the kernel to load those blocks
into the correct address_spaces. That's hard, because file data
depends on file metadata. A vast simplification would be to do it in
two disk passes: read all the metadata on pass 1 then all the data on
pass 2.
Yes, that is what this patchset tries to do.
A totally different approach is to reorder all the data and metadata
on-disk, so no special cold-boot processing is needed at all.
The boot time speedup mentioned in the changelog won't be possible
without the physical data/metadata reordering. Fortunately btrfs makes
it a trivial task.
And a third approach is to save all the cache into a special
file/partition/etc and to preload all that into kernel data structures
at boot. Obviously this one is ricky/tricky because the on-disk
replica of the real data can get out of sync with the real data.
Hah! We are thinking much alike :)
It's a very good optimization for LiveCDs and readonly mounted NFS /usr.
For a typical desktop, the solution in my mind is to install some
initscript to run at halt/reboot time, after all other tasks have been
killed and filesystems remounted readonly. At the time it may dump
whatever in the page cache to the swap partition. At the next boot,
the data/metadata can then be read back _perfectly sequentially_ for
populating the page cache.
For kexec based reboot, the data can even be passed to next kernel
directly, saving the disk IO totally.
Thanks,
Fengguang