Vladimir Zhurkin

#!/bin/bash
# Get current swap usage for all running processes
# Erik Ljungstrom 27/05/2011
# Modified by Mikko Rantalainen 2012-08-09
# Pipe the output to "sort -nk3" to get sorted output
# Modified by Marc Methot 2014-09-18
# removed the need for sudo

SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
PID=`echo $DIR | cut -d / -f 3`
PROGNAME=`ps -p $PID -o comm --no-headers`
for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
do
let SUM=$SUM+$SWAP
done
if (( $SUM > 0 )); then
echo "PID=$PID swapped $SUM KB ($PROGNAME)"
fi
let OVERALL=$OVERALL+$SUM
SUM=0
done
echo "Overall swap used: $OVERALL KB"

Цель добиться полностью готовой к работе виртуальной машины размером гигов 15-20

find . -name "&*" -a -name "*IMAP" | sed -e 's|.*&||; s|-.*|| '

заменил минус на 2 равно

Вопросы:
1. SSD или HDD лучше для этого использовать?
2. Какая файловая система подойдет наилучшим образом?
3. Как быстро диск от подобного погибнет?

Ежедневно стандартными средствами NodeJS будет создаваться порядка ~100k архивов zip в день.
Размер каждого архива <1кб.
Хранить каждый из них нужно порядка месяца.

Если нода недоступна - все запросы должны идти на другую. Можно ли это реализовать?

только для развертывания на нем виртуальной машины, уважаемы подскажите пожалуйста какую OS выбрать?
Требования :
Легкая
Быстрая

Нет проблем с установкой wi-fi модуля(dlink)
Использовать буду только для запуска виртуальной машины

Объясню как "домохозяйка".
При выключении и включении компьютера в консоль при загрузке выводятся некоторые данные. Можно ли их каким-то образом посмотреть после загрузки?

ввиду ПО minecraft, а под апдейтом имелась ввиду редактирование файлов внутри этой папки.

Yes, it is highly recommended to make additional backup of the metadata file. This provides a
worst case recovery option if, for some reason, the metalogger data is not useable for restoring
the master server (for example the metalogger server is also destroyed).
The master server flushes metadata kept in RAM to the metadata.mfs.back binary file every
hour on the hour (xx:00). So a good time to copy the metadata file is every hour on the half
hour (30 minutes after the dump). This would limit the amount of data loss to about 1.5h of
data. Backing up the file can be done using any conventional method of copying the metadata
file – cp, scp, rsync, etc.
After restoring the system based on this backed up metadata file the most recently created files
will have been lost. Additionally files, that were appended to, would have their previous size,
86
which they had at the time of the metadata backup. Files that were deleted would exist again.
And files that were renamed or moved would be back to their previous names (and locations).
But still you would have all of data for the files created in the X past years before the crash
occurred.
In MooseFS Pro version, master followers flush metadata from RAM to the hard disk once an
hour. The leader master downloads saved metadata from followers once a day.