惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
Security @ Cisco Blogs
罗磊的独立博客
宝玉的分享
宝玉的分享
Last Week in AI
Last Week in AI
T
The Blog of Author Tim Ferriss
美团技术团队
T
Tailwind CSS Blog
博客园 - 三生石上(FineUI控件)
博客园 - Franky
G
Google Developers Blog
Jina AI
Jina AI
Stack Overflow Blog
Stack Overflow Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
V
Visual Studio Blog
腾讯CDC
S
SegmentFault 最新的问题
Recent Announcements
Recent Announcements
博客园 - 叶小钗
Microsoft Security Blog
Microsoft Security Blog
雷峰网
雷峰网
L
LangChain Blog
Vercel News
Vercel News
Forbes - Security
Forbes - Security
PCI Perspectives
PCI Perspectives
N
News | PayPal Newsroom
S
Security Affairs
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
博客园 - 司徒正美
J
Java Code Geeks
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Hacker News: Ask HN
Hacker News: Ask HN
Schneier on Security
Schneier on Security
A
About on SuperTechFans
Attack and Defense Labs
Attack and Defense Labs
Google Online Security Blog
Google Online Security Blog
aimingoo的专栏
aimingoo的专栏
MongoDB | Blog
MongoDB | Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
酷 壳 – CoolShell
酷 壳 – CoolShell
Cloudbric
Cloudbric
B
Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
P
Proofpoint News Feed
D
DataBreaches.Net
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
B
Blog RSS Feed
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
N
News and Events Feed by Topic

博客园 - forrestsun

问题整理 weedfs getsockopt: connection timed out 利用cubieboard设置samba打印服务器 CubieTruck上安装mjpg_streamer devexpress bandgridview使用总结(14.2) WeedFS0.6.8-引用库列表 NSQ的消息订阅发布测试 WeedFS依赖库 0.6.1 golang 前置补0 MongoDB-MMS使用总结 golang 格式化时间为字符串 格式化字符串为时间学习总结 mgo-后续测试(指定字段,获取id) mgo中DBRef-数据查询测试 mgo中DBRef-数据添加测试 weed-fs 基础测试 weed-fs 压力测试 weed-fs参数列表 mgo like的两种写法
WeedFS问题收集
forrestsun · 2014-07-28 · via 博客园 - forrestsun

weed fs FAQ


Moving files to a different server

Q:

Hello,is it possible to move manually the .dat and .idx to a different volume?

A:

Moving it to a different volume server? Yes! Steps: 1. shut down the original volume server. 2. move the .dat and .idx files to the new volume server. 3. start or restart the new server. Optionally restart the original volume server if you still need it.


weed filer is slow

Q

Hi, ChrisLu, Weed-FS is Great, I tested is fast:

    ab -n 10000 -c 100 http://192.168.1.1:8080/2/014a96ba83
    > Requests per second:    6029.21 [#/sec] (mean)
    I try use "weed filer", But tested is slow:
    ab -n 10000 -c 100 http://192.168.1.1:8888/2014/05/23/1.jpg
    > Requests per second:    1885.35 [#/sec] (mean)

Could you tell me why? Thank you very much.

A

Filer does extra work, to serve a filer request: 1) filer: lookup directory in memory, this should be very fast 2) filer: lookup file "1.jpg" via leveldb 3) filer: proxy the request to weed volume 4) Volume server returns data to filer 5) filer: give the data back to client

Just compare one single file performance is not really meaningful. Put lots and lots of files under one filer folder, and randomly access one of them. Filer can handle it with fairly consistent speed without much speed degradation. That's where the power of filer shines.

Chris


a few questions about uploading a file

Q

A

In general, I think you may have some misunderstanding about fileId.

  1. when uploading a file to a volume server directly, who handles the replication, and what is the strategy for replicating(how do you choose a server in your rack or DC) ? The volume server handles replication. The replication is tied to the volume id. The volume id is assigned via the master server.
  2. when uploading a file to a master server, who handles the replication, and what is the strategy for replicating(how do you choose a server in your rack or DC) ? Same answer as above.
  3. when uploading a file via a master server, how can i set the file id(like you can do when uploading to a volume server directly) ? The master server just forward the upload request to a volume server that has this volume id.
  4. what are the limitations of the file id name, i've noticed it can take a-z, 0-9, but needs to be 12 chars long ? Please read the format definition in file_id.go. There are 3 parts in the file id <volumeid, filekey,="" cookie="">.

     type FileId struct {
         VolumeId VolumeId
         Key      uint64
         Hashcode uint32
     }
  5. is there an automatic re-replication of volumes, when a volume server fails ? No. If a volume server fails, all volumes with the same volume id on that server will become readonly.


Is 32GB per volume is an upper limit or lower limit?

Q

"Each data volume is size 32GB", what does this exactly mean? If I have a host server with 20GB disk space, will it be capable of running a volume server in it? What if I have a 40GB server, will the rest 8GB left unused? Also can I configure the data volume size to fit my needs? I'm new to weed-fs and is excited about it to use it in a production cluster having several nodes.

Btw, thanks a lot for the efforts to write this exciting file system.

A

Each "volume server" can have multiple "volume data files". Each "volume data file" currently has this 32GB limit.

For small servers as you suggested, I would recommend set the volumeSizeLimt to 10GB, and run 2 volumes on 20GB disk, run 4 volumes on 40GB disk. (of course, maybe leave some space for other purposes)

I think weed-fs currently is robust enough for many use cases. Let me know or file a bug if you see anything abnormal.

Chris