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
 |