weedfs文件使用记录
源码目录结构
核心模块
- weed 入口目录
- weed/weed_server 入口目录与HTTP服务相关
- topology 核心模块，主要包括 【DataCenter, Rack, DataNode】 三层拓扑结构。
- storage 核心模块，主要包括【Store, Volume, Needle】这三大块存储相关的源码。
辅助模块
- sequence 负责FileID的全局有序生成
- filer 提供支持 HTTP REST 操作的文件服务器，其实就是基于 leveldb 把文件名和目录结构存储起来。
- stats 和操作系统内存和磁盘使用状况有关的模块
- operation 由protobuf生成的代码们
- proto 存放protobuf的描述文件
- glog 日志模块
- images 图片服务
- util 工具函数
- tools 工具，暂时只有一个读索引的文件。
多数据节点维护之 Topology
topology 整个模块最核心的数据结构是三个：
- DataCenter
- Rack
- DataNode
topology 是树状结构，DataNode 是树的叶子节点， DataCenter 和 Rack 是树的非叶子节点， DataCenter 是 Rack 的父母节点。 如下图
DataCenter | | ------------------ | | | | Rack Rack | | ------------ | | | | DataNode DataNode也就是在 MasterServer 维护的拓扑结构里， 是把 VolumeServer 的相关信息存储在 DataNode 里， 所以在代码里面可以看到如下：
dc := t.GetOrCreateDataCenter(dcName) rack := dc.GetOrCreateRack(rackName) dn := rack.FindDataNode(*joinMessage.Ip, int(*joinMessage.Port))每次查找对应的DataNode，都需要从 DataCenter -> Rack -> DataNode 依次找下去。
数据存储
理解Fid
curl -F "file=@/tmp/test.pdf" "127.0.0.1:9333/submit" {"fid":"1,01f96b93eb","fileName":"test.pdf","fileUrl":"localhost:8081/1,01f96b93eb","size":548840}其中 "fid":"1,01f96b93eb" 就是 Fid，Fid 由三个部分组成 【VolumeId, NeedleId, Cookie】 组成。
- VolumeId: 1 32bit 存储的物理卷的Id
- NeedleId: 01 64bit 全局唯一NeedleId，每个存储的文件都不一样(除了互为备份的)。
- Cookie: f96b93eb 32bit Cookie值，为了安全起见，防止恶意攻击。
其中 VolumeId 是由 MasterServer 分配给 VolumeServer， 每个 VolumeServer 都维护个 n 个 Volume ， 每个 Volume 都有一个专属 VolumeId，之后会细说。 Needle 属于 Volume 里面的一个单元，后续说。
Volume
type Volume struct { Id VolumeId dir string Collection string dataFile *os.File nm NeedleMapper readOnly bool SuperBlock accessLock sync.Mutex lastModifiedTime uint64 //unix time in seconds }- VolumeId 通俗易懂，比如
"fid":"3,01f9896771"里面逗号前面的 3 就是 VolumeId 。 - dir 就是该 Volume 所在的目录，
- Collection 很有用，每个 Volume 只能对应同一个 Collection，不同 Collection 的图片存储在不同 Volume，后面会讲到。
- 所以同一个 Volume 只能针对某一个 Collection ，而 同一个 Collection 的图片可能分布在不同的 Volume。 dataFile 就是对应的文件句柄。
- nm NeedleMapper 看上去像是个 map ，其实是个列表，包含多个 Needle ，后面会讲到。
- readOnly 是否只读
- SuperBlock 超块，后面会讲到。
- accessLock 互斥锁
- lastModifiedTime 最近修改时间
以上最关键的两个点就是 SuperBlock 和 NeedleMapper ， 这两者在文件中布局如下：
+-------------+ |SuperBlock | +-------------+ |Needle1 | +-------------+ |Needle2 | +-------------+ |Needle3 | +-------------+ |Needle ... | +-------------+ Volume = 1 SuperBlock + n NeedleSuperBlock
/* * Super block currently has 8 bytes allocated for each volume. * Byte 0: version, 1 or 2 * Byte 1: Replica Placement strategy, 000, 001, 002, 010, etc * Byte 2 and byte 3: Time to live. See TTL for definition * Rest bytes: Reserved */ type SuperBlock struct { version Version ReplicaPlacement *ReplicaPlacement Ttl *TTL }SuperBlock 内维护的数据基本上就是该 Volume 的元数据。
- ReplicaPlacement : 在后面的 Replication 会讲
- Ttl :Time To Live 为了定时删除的功能
【TTL】
定时删除功能，这个感觉很酷炫，但是在Seaweedfs里面的实现原理很简单， 按 Volume 来进行分块，当每次用户上传一个自带TTL的文件（需要定时删除的文件）时， 会把这个文件存储在合适的 Volume 里面（如何选出合适的 Volume 之后再说）， 存储的时候每个文件会带有 TTL 这个属性， 当读取出来之后发现该文件已经过期（超时时间到），则会返回一个 Not Found 结果， 而每个 Volume 维护一个最大超时时间，当这个时间抵达时，说明整个 Volume 所有的文件都超时了， 然后 VolumeServer 通知 MasterServer 这个 Volume 已经被标识为 Dead 状态， 意味着 MasterServer 不会再为这个 Volume 分配新的 Fid。 然后再经过一段合适的时间后由 VolumeServer 将这个 Volume 从磁盘上安全的删除掉。 详细请看在 Seaweedfs 自带的文档 ttl ，
Needle
/* * A Needle means a uploaded and stored file. * Needle file size is limited to 4GB for now. */ type Needle struct { Cookie uint32 `comment:"random number to mitigate brute force lookups"` Id uint64 `comment:"needle id"` Size uint32 `comment:"sum of DataSize,Data,NameSize,Name,MimeSize,Mime"` Data []byte `comment:"The actual file data"` DataSize uint32 `comment:"Data size"` //version2 Flags byte `comment:"boolean flags"` //version2 NameSize uint8 //version2 Name []byte `comment:"maximum 256 characters"` //version2 MimeSize uint8 //version2 Mime []byte `comment:"maximum 256 characters"` //version2 LastModified uint64 //only store LastModifiedBytesLength bytes, which is 5 bytes to disk Ttl *TTL Checksum CRC `comment:"CRC32 to check integrity"` Padding []byte `comment:"Aligned to 8 bytes"` }Needle 结构体里面的 Cookie 和 Id 就是上文提过的 Fid 里面的 Cookie 和 NeedleId， 其他就是一些存储相关的变量，没什么奇淫巧计。就是简单的存储结构而已。
数据备份之 Replication
Replication 和 Topology 严重相关， 在配置文件中可以配置多种备份模式，详见 seaweedfs-wiki 。
+-----+---------------------------------------------------------------------------+ |001 |replicate once on the same rack | +-----+---------------------------------------------------------------------------+ |010 |replicate once on a different rack in the same data center | +-----+---------------------------------------------------------------------------+ |100 |replicate once on a different data center | +-----+---------------------------------------------------------------------------+ |200 |replicate twice on two other different data center | +-----+---------------------------------------------------------------------------+比如在 001 模式，即在同一个 rack 中的不同 DataNode 中备份一份。 假设在 rack1 中含有 DataNode1, DataNode2, DataNode3 三个数据节点中【随机】选出两个数据节点， 比如选出 DataNode1, DataNode2 然后同时写入这两个数据节点。 假设 rack1 只有一个数据节点的时候，而备份模式是 001 模式， 则无法正常备份，服务会报错。
注意到，选择备份数据节点的方法是【随机】，所以就会出现从三个数据节点中随机选择两个的情况下，
curl -v -F "file=@/tmp/test.json" localhost:8081/5,1ce2111f1topo.NextVolumeId 负责生成 VolumeId ， 负责在 VolumeGrowth 里的时候分配 Volume 的时候， 生成一个全局唯一的新 VolumeId， 在 Weed-fs 中，是支持 多 MasterServer 集群的。 当有多个 MasterServer，生成一个全局唯一的新 VolumeId 是很重要， 在 Weed-fs 中是通过 goraft 来实现的。
【强一致性】
Seaweedfs 的备份实现是强一致性的。 当一个 VolumeServer 接受到上传文件的 POST 请求时， 将该文件作为一个 Needle 写入本地 Volume 之后， 会根据该文件所分配的 VolumeId 判断是否需要备份， 如果需要备份，则进行备份（需要请求另外其它的 VolumeServer 服务器）。 过程详见 ReplicatedWrite (topology/store_replicate.go)。 当备份完毕后，再对该 POST 请求进行答复。 所以用户每次上传图片时，当收到了答复之后， 则可以认为此备份已完成。这个和最终一致性不同，属于强一致性。
上述实现强一致性的过程中， 有个必要条件就是【 VolumeServer 需要知道往其它那些 VolumeServer 备份】。 在 Seaweedfs 的实现中是借助 MasterServer 来实现， 因为备份的基本单位是 Volume, 在 MasterServer 中，对每个 VolumeId 都维护对应的备份机器列表。 可以通过如下示例命令查看:
curl "localhost:9333/dir/lookup?volumeId=4&pretty=y" { "volumeId": "4", "locations": [ { "url": "127.0.0.1:8081", "publicUrl": "localhost:8081" }, { "url": "127.0.0.1:8080", "publicUrl": "localhost:8080" } ] }如上示例中可以看出，对应的 volumeId=4 的 Volume, 可以看出对应的备份机器列表有两台，分别是 "127.0.0.1:8081" 和 "127.0.0.1:8080" 。
实际上对于每台 VolumeServer 查找其它备份机器的时候， 也是通过如上 HTTP api 向 MasterServer 询问。 只不过不是每次都询问，因为只要询问过了之后就会缓存下来，只有在缓存里面找不到才询问。
【Collection】
示例如下：
启动 MasterServer
weed master启动 VolumeServer
weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080申请Fid
curl "http://127.0.0.1:9333/dir/assign?collection=pictures" {"fid":"4,01d50c6fbf","url":"127.0.0.1:8080","publicUrl":"localhost:8080","count":1}curl "http://127.0.0.1:9333/dir/assign?collection=mp3" {"error":"No free volumes left!"}curl "http://127.0.0.1:9333/dir/assign?collection=pictures" {"fid":"5,0147ed0fb7","url":"127.0.0.1:8080","publicUrl":"localhost:8080","count":1}申请Fid的示例解释：
- 因为默认情况下，VolumeServer 启动时， 未申请任何 Volume，当第一次
/dir/assign的时候， 会分配 Volume，因为weed volume的参数-max=5所以一次性分配 5 个 Volume ，并且这 5 个 Volume 的 Collection 属性都是 pictures， 甚至可以看到在ls /tmp/data1的结果如下：
/tmp/data1 pictures_1.dat pictures_1.idx pictures_2.dat pictures_2.idx pictures_3.dat pictures_3.idx pictures_4.dat pictures_4.idx pictures_5.dat pictures_5.idx可以看出每个卷的文件名以 Collection 来命名。
2. 因为已有的 5 个 Volume 的 Collection 属性都是 pictures， 所以此时如果需要 /dir/assign 一个非 pictures Collection 的 Fid 时失败，
3. 当申请一个属于 pictures Collection 的 Fid 成功。
也就是在每次申请 Fid 时，会针对 Collection 进行检查，来保证存入 Volume 的每个 Needle 所属的 Collection 一致。 在实际应用中可以通过 Collection 来类别的分片。
【Volume 的大小限制】
在每次 VolumeServer 向 MasterServer 发送心跳信息的时候， 会在 storage.VolumeInfo.Size 里面注明当前 Volume 的大小信息(Size)。 所以可以以此来限制 Volume 的大小。 如下函数：
func (vl *VolumeLayout) isWritable(v *storage.VolumeInfo) bool { return uint64(v.Size) < vl.volumeSizeLimit && v.Version == storage.CurrentVersion && !v.ReadOnly }当 VolumeInfo.Size 大于 VolumeLayout.volumeSizeLimit 时， 则将该 Volume 标记为不可写。 而 VolumeLayout.volumeSizeLimit 的值可以在启动 MasterServer 的时候配置。 由 weed help master 可知：
-volumeSizeLimitMB=30000: Master stops directing writes to oversized volumes.每个 Volume 的最大 Size 默认是 30G , 而每个 VolumeServer 可以配置 n 个 Volume，根据所在机器不同的硬盘大小配置不同的 n . 由 weed help volume 可知：
-max="7": maximum numbers of volumes, count[,count]...每个 VolumeServer 默认的 Volume 大小是 7 。
所以默认情况下，当一个 VolumeServer 使用的磁盘超过 7 * 30G = 210G 之后， 该 VolumeServer 属于只读状态， MasterServer 不会再分配新的 Fid 给它。
但是其实这里会有漏洞，如果此时不通过请求 MasterServer 获取 Fid， 而是直接自己构造 Fid 向 VolumeServer POST 文件的话， VolumeServer 还是会一直接受上传的文件， 直到大小超过在storage/needle.go 里面写死的一个常量：
MaxPossibleVolumeSize = 4 * 1024 * 1024 * 1024 * 8其实在 VolumeServer 里面也有维护一个变量叫 volumeSizeLimit ，
type Store struct { ... volumeSizeLimit uint64 //read from the master ... }此变量的值是从 MasterServer 获取的， 当每次 VolumeServer 写入 Needle 到 Volume 的时候， 都会检查 Volume Size 是否超过 volumeSizeLimit , 当超过的时候会打错误日志， 但是不会停止写入，也就是不会拒绝上传的文件。 有且只有 当大小超过 MaxPossibleVolumeSize 的时候才会拒绝写入磁盘。
【扩容】
对于 Seaweedfs 来说，扩容非常简单，
启动 MasterServer:
./weed master -mdir="/tmp/weed_master_tmp"启动 VolumeServer1:
weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080当 VolumeServer1 因为抵达 Volume 大小上限而无法继续接受上传数据时， 此时继续 submit 上传数据 MasterServer 则会返回错误(因为在 MasterServer 内已经将 VolumeServer1 标记为不可写)。
curl -F "file=@/tmp/test.pdf" "127.0.0.1:9333/submit" {"error":"No free volumes left!"}此时直接再启动 VolumeServer2 即可
weed volume -dir="/tmp/data2" -max=5 -mserver="localhost:9333" -port=8081此时 VolumeServer2 启动之后会自动向 MasterServer 的 Topology 结构注册新的 DataNode , 当 MasterServer 接受到新的 submit 请求的时候，会将该上传文件写入 VolumeServer2 （因为此时 VolumeServer1 已经不可写）。
也就是说如果当线上出现容量问题的时候，扩容只需要加机器即可，简单有效。
总结
- 每个 MasterServer 通过 Topology 维护多个 VolumeServer 。
- 每个 VolumeServer 维护多个 Volume 。
- 每个 Volume 包含多个 Needle ，Needle 即文件。
- 多台 VolumeServer 之间的多机备份实现是强一致性。
- 多台 MasterServer 之间的主从关系是是通过 goraft 实现。
-
1.架构
我们先了解一个概念：见附录
一个master：
作为cluster管理一个DataCenter名叫imgdatacenter1（抽象的概念）；
imgdatacenter1包含一个机柜 rack名叫imgrack1（抽象的概念）；
imgrack1机柜里面有一个DataNode名叫datanode1（可以认为DataNode是一个volume server ）；cd /home1/seaweeddir //这是我的测试目录，你这里选择你自己的目录 mkdir {mtmp,vtmp1,vtmp2,ftmp,mountdir} //大括号内千万别多空格，否则会出现问题 weed master -ip=localhost -port=9333 -mdir=./mtmp (mtmp是你自定义的保存生成的序列文件id的文件夹)一个DataNode：（datanode1只是抽象的名字没有实质的代码赋值，下面通过地址来区分DataNode）
就是上面的datanode1，定义里面有10个volume，collection不先设置，DataCenter和rack都用下面的指令指定：
weed volume -dataCenter=imgdatacenter1 -rack=imgrack1 -ip=localhost -port=9991 -dir=./vtmp1 -max=10 -mserver=localhost:9333此时就在名为imgdatacenter1的dataCenter中的名为imgrack1的rack里添加了一个地址为localhost:9991的volume server。
一个filer服务器
weed scaffold -config=filer -output=. //先生成filer.toml文件默认使用leveldb保存映射关系，打开filer.toml文件修改保存映射文件的文件夹为ftmp（自定义）
image.png
然后启动filer服务
weed filer -ip=localhost -port=8888 -master=localhost:9333本地映射filer
mountdir 是本地任意目录，filer.path后面跟你想映射的filer中的目录，可以直接映射根目录。
sudo weed mount -filer=localhost:8888 -dir=/home1/seaweeddir/mountdir -filer.path=/ //sudo weed mount -filer=localhost:8888 -dir=~/folder_on_seaweedfs -filer.path=/home/chris -collection=chris关闭挂在需要关闭mount并且手动umont ~/mdir目录，如果一般用户失败请使用root用户
2.验证
我们验证下我们的服务启动状态，
此时有一个DataCenters名为imgdatacenter1，一个Racks名为imgrack1，一个DataNodes地址是localhost:9991，且该DataNode的Volumes个数为0，等我们新增文件的时候就会发现volumes个数才会增加//这种返回表示master启动成功且作为了leader curl "http://localhost:9333/cluster/status?pretty=y" { "IsLeader": true, "Leader": "localhost:9333" } //此时有一个DataCenters名为imgdatacenter1，一个Racks名为imgrack1，一个DataNodes地址是localhost:9991，且该DataNode的Volumes个数为0 curl "http://localhost:9333/dir/status?pretty=y" { "Topology": { "DataCenters": [ { "Free": 10, "Id": "imgdatacenter1", "Max": 10, "Racks": [ { "DataNodes": [ { "Free": 10, "Max": 10, "PublicUrl": "localhost:9991", "Url": "localhost:9991", "Volumes": 0 } ], "Free": 10, "Id": "imgrack1", "Max": 10 } ] } ], "Free": 10, "Max": 10, "layouts": null }, "Version": "1.10" }本地操作的方式往服务器新增一个文件
cd /home1/image/mountdir cp /home1/image/1.jpg ./我们查看下系统状态，（详细数据参见附录：上传文件后的系统状态）
此时我们发现地址为localhost:9991的datanode的Volumes数量变成了7个，说明当前新增了7个volume，因为我们之前设置的volume最大个数时10，所有最多还能再新增3个volume。
我们再看layouts，发现已经不是之前的null了，而是出现了一个名为""的collection，有七个可以写的volume。
这是因为如果我们没有指定collection的时候，默认所有数据都保存在名为""的collection中我们查看下文件上传后volumeserver的状态
我们发现id为4的volume的filecount为1，说明该文件上传到了这里。我们你再看下filer的状态
多了个1.jpg文件我们再看下我们的挂载目录
ls /home1/seaweeddir/mountdir/ 1.jpg此时说明我们上传文件就成功了
此时我们可以操作本地文件系统中的目录/home1/seaweeddir/mountdir，来操作我们的图片服务器。
然而批量操作本地文件系统的mount文件夹时不是并发的，需要经过fuse层，要想并发操作就需要直接操作filer服务。通过filer服务器做一些文件操作
使用命令上传
curl -F [email protected] "http://localhost:8888/javascript/new_name.js" # upload the file with a different name本地批量上传文件
使用weed filer.copy file_or_dir1 [file_or_dir2 file_or_dir3] http://localhost:8888/path/to/a/folder/ （多线程且绕过fuse层）
我在本地/home1/image/staff 下有大量的图片，这里上传到filer服务器的mystaff下，我们查看/home1/seaweeddir/mountdir/下，会发现多了个staff目录，且目录下也全部拷贝了图片。weed filer.copy /home1/image/staff http://localhost:8888/mystaff删除文件
curl -X DELETE http://localhost:8888/path/to/file删除文件夹
curl -X DELETE http://localhost:8888/path/to/dir?recursive=true一些注意事项
1.关闭volume mount时需要手动sudo mount -l /home1/seaweeddir/mountdir目录，否则该目录会导致终端卡死。
2.删除操作不会马上清空磁盘，要想实时清空未使用的空间，请执行
curl "http://localhost:9333/vol/vacuum"使用fid操作文件在filer的显示
curl http://localhost:9333/dir/assign {"fid":"7,03a0146c8ac8","url":"localhost:9991","publicUrl":"localhost:9991","count":1} curl -F file=@/home1/image/1.jpg http://localhost:9991/7,03a0146c8ac8 //在filer中找不到,因为filer服务没有保存映射关系，所有想使用filer，就得使用filer上传文件，否则只能通过fid获取信息。 curl -F file=@/home1/image/1.jpg "http://localhost:8888/javascript/2.jpg"//在filer的javascript目录下多了个2.jpg weed download -server="localhost:9333" -dir="D:\data3" 4,012d48fa67 //可以通过fid下载文件结尾
到这里一个图片服务器就搭建起来了，
真正要熟悉使用seaweedfs需要仔细阅读官方wiki，并且查看源码和实现依赖的论文来了解实现原理。
剩余的像数据备份，服务器云备份等请看官网wiki：
https://github.com/chrislusf/seaweedfs/wiki/Failover-Master-Server
https://github.com/chrislusf/seaweedfs/wiki/Amazon-S3-API
https://github.com/chrislusf/seaweedfs/wiki/Async-Replication-to-another-Filer总结
cd /home1/seaweeddir mkdir {mtmp,vtmp1,vtmp2,ftmp,mountdir} weed scaffold -config=filer -output=. vim filer.toml (修改leveldb的dir为"./ftmp") weed master -ip=localhost -port=9333 -mdir=./mtmp weed volume -dataCenter=imgdatacenter1 -rack=imgrack1 -ip=localhost -port=9991 -dir=./vtmp1 -max=10 -mserver=localhost:9333 weed filer -ip=localhost -port=8888 -master=localhost:9333 -collection=test sudo weed mount -filer=localhost:8888 -dir=/home1/seaweeddir/mountdir -filer.path=/ -collection=test //关闭服务后执行 sudo umount -l /home1/seaweeddir/mountdir 取消挂载 //此时就可以使用filer通过web操作文件了，而且也可以通过/home1/seaweeddir/mountdir本地操作文件了。 //或者这么理解，sudo weed mount只能用sudo umount -l 取消挂载，而不是直接kill进程。附录：
其他上传下载的命令
weed upload -master=localhost:9333 file1 [file2 file3] weed upload -master=localhost:9333 -dir=one_directory -include=*.pdf//指定几个fid下载到本地one_directory中 weed download -server=localhost:9333 -dir=one_directory fid1 [fid2 fid3 ...]//导出id为7的volume到/dir/name.tar，/tmp是volume保存的地址，只导出比2006-01-02T15:04:05新的文件 weed export -dir=/tmp -volumeId=7 -o=/home1/seaweeddir/exp2/name.tar -fileNameFormat={{.Name}} -newer='2006-01-02T15:04:05'一些概念
1.topology 是树状结构，DataNode 是树的叶子节点， DataCenter 和 Rack 是树的非叶子节点， DataCenter 是 Rack 的父母节点。
2.在 MasterServer 维护的拓扑结构里， 是把 VolumeServer 的相关信息存储在 DataNode 里,每次查找对应的DataNode，都需要从 DataCenter -> Rack -> DataNode 依次找下去。
3."fid":"1,01f96b93eb" 就是 Fid，Fid 由三个部分组成 【VolumeId, NeedleId, Cookie】 组成VolumeId: 1 32bit 存储的物理卷的Id NeedleId: 01 64bit 全局唯一NeedleId，每个存储的文件都不一样(除了互为备份的)。 Cookie: f96b93eb 32bit Cookie值，为了安全起见，防止恶意攻击4.VolumeId 是由 MasterServer 分配给 VolumeServer， 每个 VolumeServer 都维护个 n 个 Volume ， 每个Volume 都有一个专属 VolumeId，之后会细说。 Needle 属于 Volume 里面的一个单元
5.dir 就是该 Volume 所在的目录，
6.Collection 很有用，每个 Volume 只能对应同一个 Collection，不同 Collection 的图片存储在不同 Volume，所以同一个 Volume 只能针对某一个 Collection ，而 同一个 Collection 的图片可能分布在不同的 Volume
7.Replication 和 Topology 严重相关,比如在 001 模式，即在同一个 rack 中的不同 DataNode 中备份一份。假设在 rack1 中含有 DataNode1, DataNode2, DataNode3 三个数据节点中【随机】选出两个数据节点， 比如选出 DataNode1, DataNode2 然后同时写入这两个数据节点。 假设 rack1 只有一个数据节点的时候，而备份模式是 001 模式， 则无法正常备份，服务会报错。
8.VolumeServer 启动时， 未申请任何 Volume，当第一次 /dir/assign 的时候， 会分配 Volume
9.每个 VolumeServer 默认的 Volume 大小是 7 。默认情况下，当一个 VolumeServer 使用的磁盘超过 7 *30G = 210G 之后， 该 VolumeServer 属于只读状态， MasterServer 不会再分配新的 Fid 给它。
10.每个 MasterServer 通过 Topology 维护多个 VolumeServer 。
11.每个 VolumeServer 维护多个 Volume 。
12.每个 Volume 包含多个 Needle ，Needle 即文件。
13.多台 VolumeServer 之间的多机备份实现是强一致性。
14.多台 MasterServer 之间的主从关系是是通过 goraft 实现。collection的说明
如果我们没有指定collection的时候，默认所有数据都保存在名为""的collection中，
0.按照collection删除Delete Collection curl "http://localhost:9333/col/delete?collection=xxx&pretty=y"1.预申请volume的时候指定collection
//预申请4个属于名为turbo的collection 的volume curl "http://localhost:9333/vol/grow?collection=turbo&count=4"2.添加filer时指定collection
//此时所有通过filer新增的数据都在名为myfiler的collection中 weed filer -ip=localhost -port=8888 -master=localhost:9333 -collection=myfiler - mount时指定collection
-
//只挂在指定collection weed mount -filer=localhost:8888 -dir=~/folder_on_seaweedfs -filer.path=/home/chris -collection=chris4.其他
curl "http://127.0.0.1:9333/dir/assign?collection=pictures" curl -F @file=./hello1.txt http://10.0.40.58:9333/submit?collection=test_crash weed upload -collection myfiles -master=localhost:9333 XXX.txt上传文件后的系统状态
curl "http://localhost:9333/dir/status?pretty=y" { "Topology": { "DataCenters": [ { "Free": 3, "Id": "imgdatacenter1", "Max": 10, "Racks": [ { "DataNodes": [ { "Free": 3, "Max": 10, "PublicUrl": "localhost:9991", "Url": "localhost:9991", "Volumes": 7 } ], "Free": 3, "Id": "imgrack1", "Max": 10 } ] } ], "Free": 3, "Max": 10, "layouts": [ { "collection": "", "replication": "000", "ttl": "", "writables": [ 1, 2, 3, 4, 5, 6, 7 ] } ] }, "Version": "1.10" }我们查看下文件上传后volumeserver的状态
我们发现id为4的volume的filecount为1，说明该文件上传到了这里。curl "http://localhost:9991/status?pretty=y" { "Version": "1.10", "Volumes": [ { "Id": 1, "Size": 0, "ReplicaPlacement": { "SameRackCount": 0, "DiffRackCount": 0, "DiffDataCenterCount": 0 }, "Ttl": {}, "Collection": "", "Version": 3, "FileCount": 0, "DeleteCount": 0, "DeletedByteCount": 0, "ReadOnly": false }, { "Id": 2, "Size": 0, "ReplicaPlacement": { "SameRackCount": 0, "DiffRackCount": 0, "DiffDataCenterCount": 0 }, "Ttl": {}, "Collection": "", "Version": 3, "FileCount": 0, "DeleteCount": 0, "DeletedByteCount": 0, "ReadOnly": false }, { "Id": 3, "Size": 0, "ReplicaPlacement": { "SameRackCount": 0, "DiffRackCount": 0, "DiffDataCenterCount": 0 }, "Ttl": {}, "Collection": "", "Version": 3, "FileCount": 0, "DeleteCount": 0, "DeletedByteCount": 0, "ReadOnly": false }, { "Id": 4, "Size": 77285, "ReplicaPlacement": { "SameRackCount": 0, "DiffRackCount": 0, "DiffDataCenterCount": 0 }, "Ttl": {}, "Collection": "", "Version": 3, "FileCount": 1, "DeleteCount": 0, "DeletedByteCount": 0, "ReadOnly": false }, { "Id": 5, "Size": 0, "ReplicaPlacement": { "SameRackCount": 0, "DiffRackCount": 0, "DiffDataCenterCount": 0 }, "Ttl": {}, "Collection": "", "Version": 3, "FileCount": 0, "DeleteCount": 0, "DeletedByteCount": 0, "ReadOnly": false }, { "Id": 6, "Size": 0, "ReplicaPlacement": { "SameRackCount": 0, "DiffRackCount": 0, "DiffDataCenterCount": 0 }, "Ttl": {}, "Collection": "", "Version": 3, "FileCount": 0, "DeleteCount": 0, "DeletedByteCount": 0, "ReadOnly": false }, { "Id": 7, "Size": 0, "ReplicaPlacement": { "SameRackCount": 0, "DiffRackCount": 0, "DiffDataCenterCount": 0 }, "Ttl": {}, "Collection": "", "Version": 3, "FileCount": 0, "DeleteCount": 0, "DeletedByteCount": 0, "ReadOnly": false } ] }我们你再看下filer的状态
多了个1.jpg文件curl -H "Accept: application/json" "http://localhost:8888/?pretty=y" { "Path": "", "Entries": [ { "FullPath": "/1.jpg", "Mtime": "2018-12-18T10:38:18+08:00", "Crtime": "2018-12-18T10:38:18+08:00", "Mode": 436, "Uid": 1000, "Gid": 1000, "Mime": "image/jpeg", "Replication": "", "Collection": "", "TtlSec": 0, "chunks": [ { "file_id": "4,0189b08312", "size": 77244, "mtime": 1545100698715493243, "e_tag": "32f4abc5" } ] } ], "Limit": 100, "LastFileName": "1.jpg", "ShouldDisplayLoadMore": false }我们再看下我们的挂载目录
ls /home1/seaweeddir/mountdir/ 1.jpg