From: Michał B. <mic...@ge...> - 2010-01-29 14:59:28
|
Hi Jose! > * This open source project is essential for mass storage work, its characteristics are necessary. What exact characteristics would you like to know? If you could ask more specifically. > * GlusterFS has different ones. What do you mean here? > * The answer to question number 6 will make you unique, along with a backup procedure in real time machine to another metaserver in passive mode, ready for immediate replacement. It is possible to implement the feature of storing one copy in another group of chunkservers. Regarding backup procedure - it can be done by configuring metalogger which can start working as the master server in case of emergency. Please find the attachment on how to configure it. > * Low cost and fundamental characteristics plus a tar.gz of 15Kb, can you ask for more? > * Start the deployment to replace the secondary and tertiary servers replicated. > * Much obliged and made available to project developers, both privileged access to the cluster, like any other network or storage resources of our institution according to their convenience and free of course. Unfortunately we don't understand all these points :( > > > 2 .- Very important, vsftpd can write directly on the MFS mount point, > > > or > > > need to mount --bind. A better idea? commercial code, other > > > implementation > > > of mfsmount, native module? > > > > We are not sure if we fully understand the question, but we'll try to > > answer. > > > > There is no ready ftp server which would communicate directly with the > > master server and chunkservers so the solution is to "go through" the > > normal mfsmount. It gives better results than creating a special code for > > communication - kernel really supports I/O operations very efficiently > > (eg. by using read-ahead, buffering, writing in background, etc.). That's > > why we also use classic file systems for storing data in chunkservers > rather than using the disk directly as a block-device. > * clarifying example > > * On the client, mfs mounted in /media/mfs. > configured vsftpd root directory at: > local_root = /media/mfs/virtualusers/$USER > user_sub_token = $USER > > * Virtualusers directory physically reside in the cluster fysesystem, or > virtualusers2 3 4 5. > * Vsftpd I can not write to that directory as it really is a socket. Write operations in MooseFS are made in the same way as on any other standard file system. > * I would need to mount --bind /media/mfs /media/local and change > local_root = /media/local/virtualusers/$USER in sshfs using FUSE is necessary. > * Was it necessary in mfs? > * on vsftpd.conf , use_sendfile = NO ¿Would the solution? proves it. We can try to install vsftpd and check if there is any problem in running it with MooseFS. > > 4.- stored millions of small files, backup software cript. compress and > > > split > > > files 5/30 Mb, any advice on file systems to use ext3-ext4 or block > > > size. kernel > > > elevator, another tuning? > > > > (Again we are not fully sure about the question) > > > > At our company we do not use any tuning, just normal ext3. > > > > How many milions of files do you have? Generally speaking 1 million files > > takes approximately 300 MiB of RAM. Installation of 25 million files > > requires about 8GiB of RAM and 25GiB space on HDD. > > > > * command executed in all primary servers > find /media/volumen0/virtualusers -type f | wc -l > > Current all total 369,026,500 If you have this number of files it may be reasonable to tar the files before storing them on MooseFS. > > > 8.- What would be the best option on the clients automounter or > > > desconecction, autofs, daemon guard, cron script? > > > > We have not used mfsmount with automounter nor autofs, we think you have to > > just monitor its activity. If the master server or chunkservers are > > termporarily not available, mfsmount tries to reconnect automatically. > > > > * I understand that with the reconnect feature of mfsmount or FUSE > in /etc/fstab We have just these entries in /etc/fstab (_netdev option is specific do debian only): mfsmount /mnt/mfs fuse rw,nosuid,nodev,_netdev 0 0 We do not use any automounts, simply mfsmounts are constantly mounted and they take care of connections to the master and chunk servers. Kind regards Michał Borychowski MooseFS Support Manager _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Gemius S.A. ul. Wołoska 7, 02-672 Warszawa Budynek MARS, klatka D Tel.: +4822 874-41-00 Fax : +4822 874-41-01 |