BeeGFS读文件分析

最新推荐文章于 2024-02-27 15:03:28 发布
最新推荐文章于 2024-02-27 15:03:28 发布
阅读量343 收藏
点赞数
文章标签： 服务器 java 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/chqhong/article/details/128247528
版权

文章目录

BeeGFS读文件分析

集群部署角色

节点名节点IP节点角色软件版本
master192.168.10.100mgmtd、meta、storage、client系统版本：CentOS 7.6 软件版本：BeeGFS 7.2.4
node1192.168.10.101meta、storage、client系统版本：CentOS 7.6 软件版本：BeeGFS 7.2.4
node2192.168.10.102client系统版本：CentOS 7.6 软件版本：BeeGFS 7.2.4

在这里插入图片描述

无文件时元数据目录

在这里插入图片描述
在这里插入图片描述

新建文件时元数据目录

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

元数据目录结构

在这里插入图片描述

Meta源码分析

首先我根据file1元数据存储的目录反向分析**/beegfs_meta/meta1/dentries/38/51/root/#fSiDs#/3-6392928E-2**，分析root为何存储在38/51目录下。
dentries、inodes目录都有128*128个十六进制目录, 128个十六进制表示的level1级目录，每个level1下有128个十六进制表示的level2级目录，总共16384个目录；
根据资料可知3-6392928E-2，这个FileID文件的名字组成结构为**--。
其中counterPart起计数作用，新增inode：idCounter+1；timestampPart为时间戳；localNodeID根据结果来看可能是对应元数据存储的节点。
文档中有提到FileID的32位hash字符串，高16位%128，得到level1目录，低16位%128，得到level2目录，hash算法使用的是hash算法Paul Hsieh**。但是没有提及到是对什么字符串进行hash，我将Paul Hsieh算法运行，并输入尝试，结果如下。
在这里插入图片描述
那么结果说明其是对文件名进行hash，这也就是为什么root总是处于/38/51目录下。可以看到file3所在的目录dentries/2F/70/4-639292D3-3/也是这样得来的。且只有在新建dir时，才会新建inodes和dentries目录，新建的文件的元数据保存在其父目录元数据目录dentries/2F/70/4-639292D3-3/下。
在这里插入图片描述
根据上面的结果我猜测读取文件的过程，如读取file2，由客户端发起读取请求，元数据服务器接收到请求后，根据文件名在root元数据目录下找到dentries/38/51/root/dir1，dir1中可能存储着dir1的元数据存储节点以及FileID，也就是node1和4-6392928E-2，而localNodeID为2，也对应上面的猜测，是元数据存储节点master对应的ID。根据信息来到node1节点，根据FileID的hash结果可以找到inodes/48/1F/4-6392928E-2和dentries/48/1F/4-6392928E-2/file2。
在这里插入图片描述

可以看到目录下的file2和**#fSiDs#目录下的3-639292D3-3有相同的inode号，说明是一个硬链接。那么至此，就拿到了file2对应的FileID文件，我猜测在这个文件中有存储信息，也就是存储节点和目录的信息。从data3的存储目录中，也能看到FileID和存储路径多少有些联系，打开其FileID在存储节点对应的文件，也就是file2的内容。
在这里插入图片描述
以上是根据结果对读取结果的猜测，那么接下来就是根据源码来验证猜测了。既然文件的读写都离不开hash，那么就从hash开始入手。
在beeGFS\v7-master\common\source\common\toolkit\StorageTk.h**里能找到如下函数。


      /**
       * @return path/hashDir1/hashDir2/fileName
       */
      static std::string getHashPath(const std::string path, const std::string entryID,
         size_t numHashesLevel1, size_t numHashesLevel2)
      {
         return path + "/" + getBaseHashPath(entryID, numHashesLevel1, numHashesLevel2);
      }

      /**
       * @return (hashDir1, hashDir2)
       */
      static std::pair<unsigned, unsigned> getHash(const std::string& entryID,
         size_t numHashesLevel1, size_t numHashesLevel2)
      {
         uint16_t hashLevel1;
         uint16_t hashLevel2;

         getHashes(entryID, numHashesLevel1, numHashesLevel2, hashLevel1, hashLevel2);

         return {hashLevel1, hashLevel2};
      }

      /**
       * @return hashDir1/hashDir2/entryID
       */
      static std::string getBaseHashPath(const std::string entryID,
         size_t numHashesLevel1, size_t numHashesLevel2)
      {
         uint16_t hashLevel1;
         uint16_t hashLevel2;

         getHashes(entryID, numHashesLevel1, numHashesLevel2, hashLevel1, hashLevel2);

         return StringTk::uint16ToHexStr(hashLevel1) + "/" + StringTk::uint16ToHexStr(hashLevel2) +
            "/" + entryID;
      }

在beeGFS\v7-master\common\source\common\toolkit\MetaStorageTk.h 中getMetaDirEntryPath函数使用了getHashPath。


      /**
       * Get path to a contents directory (i.e. the dir containing the dentries by name).
       *
       * @param dirEntryID entryID of the directory for which the caller wants the contents path
       */
      static std::string getMetaDirEntryPath(const std::string dentriesPath,
         const std::string dirEntryID)
      {
         return StorageTk::getHashPath(dentriesPath, dirEntryID,
            META_DENTRIES_LEVEL1_SUBDIR_NUM, META_DENTRIES_LEVEL2_SUBDIR_NUM);
      }

在beeGFS\v7-master\meta\source\net\message\fsck\RetrieveFsIDsMsgEx.cpp中RetrieveFsIDsMsgEx函数使用了getMetaDirEntryPath。


bool RetrieveFsIDsMsgEx::processIncoming(ResponseContext& ctx)
{
   LogContext log("Incoming RetrieveFsIDsMsg");
   log->log(Log_NOTICE, "Registration and management info download complete.");
   App* app = Program::getApp();
   MetaStore* metaStore = app->getMetaStore();

   unsigned hashDirNum = getHashDirNum();
   bool buddyMirrored = getBuddyMirrored();
   std::string currentContDirID = getCurrentContDirID();
   unsigned maxOutIDs = getMaxOutIDs();

   int64_t lastContDirOffset = getLastContDirOffset();
   int64_t lastHashDirOffset = getLastHashDirOffset();
   int64_t newHashDirOffset;

   FsckFsIDList fsIDsOutgoing;

   unsigned readOutIDs = 0;

   NumNodeID localNodeNumID = buddyMirrored
      ? NumNodeID(Program::getApp()->getMetaBuddyGroupMapper()->getLocalGroupID())
      : Program::getApp()->getLocalNode().getNumID();
   MirrorBuddyGroupMapper* bgm = Program::getApp()->getMetaBuddyGroupMapper();

   if (buddyMirrored &&
         (bgm->getLocalBuddyGroup().secondTargetID == app->getLocalNode().getNumID().val()
          || bgm->getLocalGroupID() == 0))
   {
      ctx.sendResponse(
            RetrieveFsIDsRespMsg(&fsIDsOutgoing, currentContDirID, lastHashDirOffset,
               lastContDirOffset));
      return true;
   }

   bool hasNext;

   if ( currentContDirID.empty() )
   {
      hasNext = StorageTkEx::getNextContDirID(hashDirNum, buddyMirrored, lastHashDirOffset,
         &currentContDirID, &newHashDirOffset);
      if ( hasNext )
         lastHashDirOffset = newHashDirOffset;
   }
   else
      hasNext = true;

   while ( hasNext )
   {
      std::string parentID = currentContDirID;
      std::string idPath = MetaStorageTk::getMetaDirEntryIDPath(
         MetaStorageTk::getMetaDirEntryPath(
            buddyMirrored
               ? app->getBuddyMirrorDentriesPath()->str()
               : app->getDentriesPath()->str(),
            parentID));

      bool parentDirInodeIsTemp = false;
      StringList outNames;
      int64_t outNewServerOffset;
      ListIncExOutArgs outArgs(&outNames, NULL, NULL, NULL, &outNewServerOffset);

      FhgfsOpsErr listRes;

      unsigned remainingOutIDs = maxOutIDs - readOutIDs;

      DirInode* parentDirInode = metaStore->referenceDir(parentID, buddyMirrored, true);

      // it could be, that parentDirInode does not exist
      // in fsck we create a temporary inode for this case, so that we can modify the dentry
      // hopefully, the inode itself will get fixed later
      if ( unlikely(!parentDirInode) )
      {
         log.log(
            Log_NOTICE,
            "Could not reference directory. EntryID: " + parentID
               + " => using temporary directory inode ");

         // create temporary inode
         int mode = S_IFDIR | S_IRWXU;
         UInt16Vector stripeTargets;
         Raid0Pattern stripePattern(0, stripeTargets, 0);
         parentDirInode = new DirInode(parentID, mode, 0, 0,
            Program::getApp()->getLocalNode().getNumID(), stripePattern, buddyMirrored);

         parentDirInodeIsTemp = true;
      }

      listRes = parentDirInode->listIDFilesIncremental(lastContDirOffset, 0, remainingOutIDs,
         outArgs);

      lastContDirOffset = outNewServerOffset;

      if ( parentDirInodeIsTemp )
         SAFE_DELETE(parentDirInode);
      else
         metaStore->releaseDir(parentID);

      if (listRes != FhgfsOpsErr_SUCCESS)
      {
         log.logErr("Could not read dentry-by-ID files; parentID: " + parentID);
      }

      // process entries
      readOutIDs += outNames.size();

      for ( StringListIter iter = outNames.begin(); iter != outNames.end(); iter++ )
      {
         std::string id = *iter;
         std::string filename = idPath + "/" + id;

         // stat the file to get device and inode information
         struct stat statBuf;

         int statRes = stat(filename.c_str(), &statBuf);

         int saveDevice;
         uint64_t saveInode;
         if ( likely(!statRes) )
         {
            saveDevice = statBuf.st_dev;
            saveInode = statBuf.st_ino;
         }
         else
         {
            saveDevice = 0;
            saveInode = 0;
            log.log(Log_CRITICAL,
               "Could not stat ID file; ID: " + id + ";filename: " + filename);
         }

         FsckFsID fsID(id, parentID, localNodeNumID, saveDevice, saveInode, buddyMirrored);
         fsIDsOutgoing.push_back(fsID);
      }

      if ( readOutIDs < maxOutIDs )
      {
         // directory is at the end => proceed with next
         hasNext = StorageTkEx::getNextContDirID(hashDirNum, buddyMirrored, lastHashDirOffset,
            &currentContDirID, &newHashDirOffset);

         if ( hasNext )
         {
            lastHashDirOffset = newHashDirOffset;
            lastContDirOffset = 0;
         }
      }
      else
      {
         // there are more to come, but we need to exit the loop now, because maxCount is reached
         hasNext = false;
      }
   }

   ctx.sendResponse(
         RetrieveFsIDsRespMsg(&fsIDsOutgoing, currentContDirID, lastHashDirOffset,
            lastContDirOffset) );

   return true;
}

最终在元数据服务器的网络消息监听meta/source/net/message/NetMessageFactory.cpp中找到了RetrieveFsIDsMsgEx。
在这里插入图片描述
根据函数的输入可以看到，确实是将收到的文件路径进行查询，在元数据服务器一步步获取到相应的FileId。按照同样的方法也找到寻找inode相关的源码，但是由于meta端源码编译没跑通，没有进一步的验证，很多东西都是靠猜测，也是一知半解。目前打算将编译跑通后先验证以上猜测，再进一步对FileId文件的存储信息进行分析。

调试问题

请添加图片描述
请添加图片描述
编译后修改了服务启动路径，可以看到日志第一行的**KERNEL-TEST!!!**是完成了修改后的编译，但是服务跑了大概5秒左右就会报错。如果是路径或者编译错误的话应该会跑不通吧，这个地方卡了很久，单机测试也试了结果也一样。

$ vi /etc/init.d/beegfs-meta
#APP_BIN=/opt/beegfs/sbin/${SERVICE_NAME}
APP_BIN=/root/beegfs-v7/beegfs_meta/build/${SERVICE_NAME}

$ vi /usr/lib/systemd/system/beegfs-meta.service
#ExecStart=/opt/beegfs/sbin/beegfs-meta cfgFile=/etc/beegfs/beegfs-meta.conf runDaemonized=false
ExecStart=/root/beegfs-v7/beegfs-meta cfgFile=/etc/beegfs/beegfs-meta.conf runDaemonized=false
chqhong
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
beegfs源码分析
yinghuo233的博客
09-26 978
BeeGFS的客户端是由一个内核模块和两个系统服务组成的，这里咱们主要分析内核模块。由于BeeGFS的目录树解析，是在父目录DEntry里找子目录或文件DEntry，逐级迭代完成的，所以在Mount文件系统时，须要从管理节点获取根元数据节点的ID，而后再向根元数据节点查询根目录的DEntry的信息，为后续的目录解析打下基础。获取类似/data/beeond/data/dentries/38/51/root/#fSiDs#/文件fileId的父路径。1.1 FileID的生成。Session网络消息。
beegfs元数据-工作流程整理20200417.docx
05-29
beegfs元数据-源码分析和客户端 读取目录缓存优化方案，在BeeGFS中用来维护文件和目录关系及其属性配置的服务，采用多线程epoll模式设计实现非常高效
BeeGFS源码分析1-元数据服务概要分析
chiminlai5815的博客
07-02 848
元数据服务是BeeGFS中用来维护文件和目录关系及其属性配置的服务，其多线程epoll设计实现非常高效，主要流程如下： ConnAcceptor(PThread)类（一个线程）负责监听端口，并接受客户端连接，然后把；连接信息（包含接收的套接字）写入管道； StreamListenerV2(P...
并行分布式文件系统BeeGFS的部署
最新发布
越努力，越幸运
02-27 1124
本文主要介绍在Linux集群中部署BeeGFS，以及遇到的问题的解决方案。
[解析]BeeGFS将是高性能计算领域的一匹黑马
Hardy
06-29 8121
简单总结: BeeGFS的轻量级架构设计和对现在高性能计算中对Burst Buffer技术需求的精确把握，加上对开源趋势和势态的开怀拥抱将力助BeeGFS在商业上获得成功。此外，BeeGFS也具备丰富的企业级软件特性(后续分享)和强大的生态伙伴，这种种迹象表明，BeeGFS无疑将会是下一个高性能计算领域的Lustre。
【开源存储】beegfs并行文件系统部署实践
Luxf0的博客
06-01 2667
BeeGFS是行业领先的并行集群文件系统，设计时优先考虑性能强大的同时，安装和管理非常方便，是I/O密集型工作负载的优质存储开源解决方案 本文主要介绍相关配置说明及实践过程
BeeGFS客户端的文件缓存
梦幻之巅
10-29 1530
从内核角度看，Linux上有Buffered IO和Direct IO两种文件IO模式，Direct IO绕过内核缓存直接将数据写入后端设备，Buffered IO先将数据写到pagecache（内核中每个文件（inode）都包含一个address_space结构（内部通过一棵基数树来管理缓存页）来管理文件缓存），然后通过内核在合适的时候（内存不足、用户发起fsync、定期flush等）将数据回写到后端设备。
beegfs源码分析-读取文件
yinghuo233的博客
09-26 501
【代码】Beegfs源码分析-读取文件。
GDS-enabled BeeGFS 人工智能并行存储解决方案
大隐隐于野
11-02 348
如下图所示, 通过在VFS层嵌入内核模块 nvidia-fs.ko 和 nvidia.ko 来管理GPU 内存地址和CPU RAM及GPU RAM的IO操作，这扩展到了PCI总线允许数据在GPU和网卡之间搬运，元数据仍然存储在CPU RAM，而数据块则允许直接读取到GPU RAM。在这样的新时代，企业需要全新的存储解决方案，才能以高效且经济的方式从容应对来势汹汹的数据洪流。Paraview是一个开源的，跨平台的数据处理和可视化程序，使用分布式的内存计算资源，能够实现对非常大的数据集的分析与处理。
BeeGFS作为Hadoop文件系统.pdf
08-26
Hadoop可以配置为使用BeeGFS作为其分布式文件系统，作为比使用HDFS更方便，更快捷的替 代方案。本页介绍了如何实现和测试此类配置。
BeeGFS介绍高可用框架读写流程文件分布系统管理说明
02-27
Introduction High Availability System Administration Conclusion
Beegfs.pdf
11-25
BeeGFS既是一个网络文件系统也是一个并行文件系统。客户端通过网络与存储服务器进行通信(具有TCP/IP或任何具有RDMA功能的互连，如InfiniBand，RoCE或Omni-Path，支持native verbs 接口)。通过BeeGFS添加更多的服务器...
ansible-role-beegfs:创建beegfs服务器和客户端
05-23
总之，BeegFS是一个并行文件系统，可将用户数据分布在多个服务器上。 它被设计为可在性能和容量方面进行扩展。 了解有关BeeFS的更多信息。 该角色上一次使用Ansible 2.5.0版进行了测试。 例子 假设我们有一个如下...
beegfs日志源码分析和日志使用
yinghuo233的博客
11-11 422
client各服务日志使用方式分析和总结
Beegfs事件监听和监控服务
yinghuo233的博客
11-07 750
beegfs事件监听和监控服务
GFS分布式文件系统
m0_73792056的博客
01-08 952
GlusterFS 是一个开源的分布式文件系统。
BeeGFS元数据优化
梦幻之巅
10-14 1281
文中设计的数据结构基于BeeGFS 7.2.2代码一句话总结：基于目录的静态分区方式，文件与父目录放在一起（本地化）文件系统初始化时，根据先来后到原则，选取第一个（注册成功）的元数据节点（组）作为系统根节点，根据根目录ID的hash值将根目录（root）预置于根节点的38/51/root路径下；创建子目录时，父目录随机选择一个元数据节点（组）作为该子目录的服务节点，创建子目录的元数据操作如下：1、在子目录的服务节点，根据子目录ID的hash值创建目录项（目录）：dentries/xx/yy/den。
BeeGFS元数据管理设计思想剖析
梦幻之巅
05-02 2146
这里写自定义目录标题Beegfs元数据管理新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 Beegfs元数据管理 换工作以后，近两年，对块存储和对象存储的关注有所减少，专注在分布式文件系统的研发上，为满足公司业务对文件存储
BeeGFS清理客户端缓存
07-25
你可以使用以下命令删除缓存文件和子目录： ``` sudo rm -rf /var/beegfs/* ``` 3. 启动 BeeGFS 客户端服务： ``` sudo systemctl start beegfs-client ``` 完成上述步骤后，BeeGFS 客户端缓存将被清理并重新启动...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值