Thank you very much! I understand it now.
On Mon, Aug 19, 2019 at 7:50 AM Robert LeBlanc <robert@xxxxxxxxxxxxx> wrote:
> The MDS manages dentries as omap (simple key/value database) entries in the metadada pool. Each dentry keeps a list of filenames and some metadata about the file such as inode number and some other info such as size I presume (can't find a documentation outlining
the binary format of the omap, just did enough digging to find the inode location).
Each directory (actually: directory fragment) is a single object in
the metadata pool. They are indexed by inode number. Root is always
inode 1 and can be used as a starting point for finding any other
directory (since the file system hierarchy is a tree). (Note: some
special directories exist outside the file system tree, like the stray
directories.)
The value in the omap Robert refers to is the binary encoded inode. It
will include the inode number, file layout (!) [1], and size. All
three of these pieces of information are necessary to find a file's
data or write new data.
> The MDS can return the inode and size
and file layout*
> to the client and the client looks up the OSDs for the inode using the CRUSH map and dividing the size by the stripe size to know how many objects to fetch for the whole object.
The file layout and the inode number determine where a particular
block can be found. This is all encoded in the name of the object
within the data pool.
[1] https://docs.ceph.com/docs/master/cephfs/file-layouts/
--
Patrick Donnelly, Ph.D.
He / Him / His
Senior Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
|
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
