عبارات برچسب‌ها (LABELS EXPRESSIONS)

برچسب‌ها حروفی هستند (A-Z - ۲۶ حرف) که می‌توانند به چانک‌سرورها اختصاص یابند. هر چانک‌سرور می‌تواند چندین برچسب (تا ۲۶ برچسب) داشته باشد. برچسب‌ها در فایل mfschunkserver.cfg تعریف می‌شوند؛ برای اطلاعات بیشتر به صفحه راهنمای مربوطه مراجعه کنید.

عبارت برچسب‌ها مجموعه‌ای از زیرعبارت‌ها است که با کاما از یکدیگر جدا شده‌اند. برای نسخه‌های کامل (کپی)، هر زیرعبارت الگوی ذخیره‌سازی یک نسخه از فایل را مشخص می‌کند. زیرعبارت می‌تواند شامل یک ستاره (*) یا یک الگوی برچسب باشد. الگوی برچسب می‌تواند یک برچسب یا عبارتی شامل جمع‌ها، ضرب‌ها، نقیض‌ها و پرانتزها باشد. جمع به این معنی است که فایل می‌تواند روی هر چانک‌سروری که با هر یک از عناصر جمع مطابقت دارد ذخیره شود (یا منطقی / OR). ضرب به این معنی است که فایل فقط روی چانک‌سروری ذخیره می‌شود که با تمام عناصر مطابقت داشته باشد (و منطقی / AND). ستاره یعنی هر چانک‌سروری. نقیض یعنی هر چانک‌سروری به جز چانک‌سروری که با زیرعبارت نفی‌شده تطبیق دارد. زیرعبارت‌های یکسان را می‌توان با افزودن یک عدد در جلوی آن خلاصه کرد به‌جای اینکه چندین بار تکرار شوند.

برای کدگذاری حذفی (EC)، عبارت برچسب با علامت @ شروع می‌شود، به دنبال آن تعداد قطعات داده، سپس علامت + و عددی که مشخص می‌کند چانک باید چند قطعه پاریتی داشته باشد. تعداد مجاز قطعات داده 4 یا 8 است. تعداد مجاز قطعات پاریتی 1 (در نسخه CE) یا 1 تا 9 (در نسخه PRO) است. بنابراین، برای مثال، @4+1 یعنی EC با ۴ قطعه داده و ۱ قطعه پاریتی، و @8+3 یعنی EC با ۸ قطعه داده و ۳ قطعه پاریتی. اگر تعداد قطعات داده حذف شود، مستر از مقدار پیش‌فرض تعریف‌شده توسط DEFAULT_EC_DATA_PARTS استفاده می‌کند - به mfsmaster.cfg(5) مراجعه کنید. در این حالت @2 به معنی @8+2 یا @4+2 خواهد بود. سپس حداکثر دو زیرعبارت می‌تواند به دنبال آن بیاید که با کاما جدا شده‌اند. اگر تنها یکی وجود داشته باشد، تعیین می‌کند که تمام قطعات کجا باید نگهداری شوند. اگر هر دو وجود داشته باشند، زیرعبارت اول تعیین می‌کند قطعات داده کجا نگهداری شوند و زیرعبارت دوم تعیین می‌کند قطعات پاریتی کجا نگهداری شوند.

عبارت برچسب‌ها می‌تواند یک عبارت برچسب معمولی یا عبارت برچسب EC باشد (یعنی عبارت برچسب EC نمی‌تواند یک زیرعبارت باشد). عبارت برچسب EC تنها می‌تواند به‌جای ARCHIVE_LABELS یا TRASH_LABELS در تعریف کلاس ذخیره‌سازی استفاده شود، اما عبارت برچسب معمولی در هر جایی قابل استفاده است.

در انتهای هر عبارت برچسب می‌توان یک یا دو اطلاعات تکمیلی اضافه کرد که با یک جداکننده ویژه تفکیک می‌شوند. اولین افزونه ممکن، افزونه تمایز (distinguish) است و جداکننده آن علامت اسلش (/) است. دومی بازنویسی حالت برچسب‌ها است که با علامت دونقطه (:) جدا می‌شود.

افزونه تمایز می‌تواند فهرستی از برچسب‌ها یا یکی از رشته‌های ویژه زیر باشد:

[IP] یا [I] - تمایز بر اساس شماره IP

[RACK] یا [R] - تمایز بر اساس رک (RACK)، همان‌طور که در توپولوژی تعریف شده است؛ به mfstopology.cfg(5) مراجعه کنید.

در صورت وجود، بخش تمایز به سامانه می‌فهماند که باید سعی کند نسخه‌های کامل را طوری توزیع کند که هر نسخه روی یک برچسب متفاوت از فهرست یا روی چانک‌سروری با نشانی IP متفاوت یا از رکی متفاوت باشد. برای EC، بخش تمایز در حال حاضر نادیده گرفته می‌شود.

توجه! اگر CHUNKS_UNIQUE_MODE در mfsmaster.cfg با مقداری غیر از ۰ تعریف شده باشد، هرگونه تنظیم تمایز در کلاس‌های ذخیره‌سازی را لغو خواهد کرد. برای اطلاعات بیشتر در مورد این پارامتر به راهنمای mfsmaster.cfg(5) مراجعه کنید.

افزونه بازنویسی حالت برچسب‌ها می‌تواند یکی از سه نویسه باشد: d (یا D یا به شکل رشته std، Std، STD)، s (یا S یا به شکل رشته strict، Strict، STRICT) یا l (یا L یا به شکل رشته loose، Loose، LOOSE) و این بدان معناست که حالت برچسب STANDARD، STRICT یا LOOSE به ترتیب باید تنها روی همین یک عبارت برچسب اعمال شود. برای توضیحات درباره حالت‌های برچسب به بخش LABEL MODES مراجعه کنید.

یک یا هر دو افزونه می‌توانند برای هر عبارت برچسب وجود داشته باشند؛ هر کدام باید با جداکننده خود آغاز شوند و در صورت وجود هر دو، ترتیب باید حفظ شود، یعنی افزونه تمایز ابتدا و افزونه حالت برچسب دوم باشد.

مثال‌هایی از عبارات برچسب‌ها:

A,B - فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی چانک‌سرور(های) دارای برچسب A و دیگری روی چانک‌سرور(های) دارای برچسب B ذخیره می‌شود.

A,* - فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی چانک‌سرور(های) دارای برچسب A و دیگری روی هر چانک‌سروری ذخیره می‌شود.

A,!A - فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی چانک‌سرور(های) دارای برچسب A و دیگری روی هر چانک‌سروری که فاقد برچسب A باشد ذخیره می‌شود.

*,* - فایل‌ها دارای دو نسخه خواهند بود که روی هر چانک‌سروری (متفاوت برای هر نسخه) ذخیره می‌شوند.

AB,C+D+E - فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی هر چانک‌سروری که هر دو برچسب A و B را دارد (ضرب برچسب‌ها) و دیگری روی هر چانک‌سروری که برچسب C یا D یا E را دارد (جمع برچسب‌ها) ذخیره می‌شود.

A,B[X+Y],C[X+Y] - فایل‌ها دارای سه نسخه خواهند بود؛ یک نسخه روی چانک‌سرور با برچسب A، نسخه دوم روی چانک‌سروری با برچسب B و یکی از برچسب‌های X یا Y، و نسخه سوم روی چانک‌سروری با برچسب C و یکی از برچسب‌های X یا Y ذخیره می‌شود.

عبارت 2A معادل عبارت A,A است.

عبارت A,3BC معادل عبارت A,BC,BC,BC است.

عبارت 2 معادل 2* و معادل *,* است.

3*/[IP] - فایل‌ها ۳ نسخه خواهند داشت و هر نسخه روی چانک‌سروری با نشانی IP متفاوت نگهداری می‌شود.

A,B/[RACK] - فایل‌ها ۲ نسخه خواهند داشت؛ یک نسخه روی چانک‌سرور با برچسب A و دیگری روی چانک‌سرور با برچسب B در رکی متفاوت از نسخه دیگر ذخیره می‌شود.

S,H,H/ABX-Z - فایل‌ها ۳ نسخه خواهند داشت؛ یکی روی سرور با برچسب S، دو تا روی سرورهای با برچسب H، اما هر نسخه روی سروری با برچسب متفاوت از مجموعه A، B، X، Y، Z خواهد بود.

@4+1 - فایل‌ها در قالب EC نگهداری می‌شوند: ۴ قطعه داده و ۱ قطعه پاریتی.

@8+3 - فایل‌ها در قالب EC نگهداری می‌شوند: ۸ قطعه داده و ۳ قطعه پاریتی.

@2 - فایل‌ها در قالب EC نگهداری می‌شوند: تعداد پیش‌فرض قطعات داده، ۲ قطعه پاریتی.

@4+3,Z - فایل‌ها در قالب EC نگهداری می‌شوند: ۴ قطعه داده و ۳ قطعه پاریتی - همگی روی چانک‌سرورهای با برچسب Z.

@2,A(X+Y) - فایل‌ها در قالب EC نگهداری می‌شوند: تعداد پیش‌فرض قطعات داده، ۲ قطعه پاریتی؛ تمام قطعات روی چانک‌سرورهایی با برچسب A و یکی از X یا Y نگهداری می‌شوند.

@3,S,H - فایل‌ها در قالب EC نگهداری می‌شوند: تعداد پیش‌فرض قطعات داده روی سرورهای با برچسب S، و ۳ قطعه پاریتی روی سرورهای با برچسب H نگهداری می‌شوند.

AB,AC:l - فایل‌ها در قالب کپی نگهداری می‌شوند؛ یک نسخه روی سرور با برچسب‌های A و B، نسخه دوم روی سرور با برچسب‌های A و C و رفتار این عبارت در حالت LOOSE خواهد بود.

@4+2,X,Y:s - فایل‌ها در قالب EC نگهداری می‌شوند؛ ۴ قطعه داده روی سرورهای با برچسب X، ۲ قطعه پاریتی روی سرورهای با برچسب Y و رفتار این عبارت در حالت STRICT خواهد بود.

2A/[IP]:s - فایل‌ها باید در ۲ نسخه نگهداری شوند، هر دو نسخه روی سرورهای با برچسب A، اما هر سرور باید IP متفاوتی داشته باشد و رفتار آن در تطبیق برچسب‌ها STRICT باشد.

حالت‌های برچسب (LABEL MODES)

تعیین اینکه در صورت عدم امکان برآورده ساختن الزامات برچسب‌های یک کلاس ذخیره‌سازی چه باید کرد، بسیار مهم است؛ یعنی در شرایطی مانند: نبود فضای کافی روی تمام سرورهای دارای برچسب‌های لازم، نبود تعداد کافی سرور با برچسب‌های لازم، یا مشغول بودن تمام سرورهای دارای برچسب‌های لازم. مسئله این است که آیا سامانه باید چانک‌ها را روی سرورهای دیگر (با برچسب‌های نامنطبق) ایجاد کند یا خیر. این تصمیم باید توسط کاربر اتخاذ شود.

سه حالت کاری وجود دارد: STANDARD، LOOSE و STRICT. این حالت‌ها بسته به اینکه چانک در قالب کپی یا EC ذخیره شود، به دلیل ماهیت و الگوریتم‌های متفاوت هر قالب، عملکرد متفاوتی دارند.

برای قالب کپی (copies)، این ۳ حالت به شرح زیر عمل می‌کنند:

در حالت STANDARD در صورت بار بیش از حد سرورها (overloaded)، سامانه منتظر آن‌ها می‌ماند، اما در صورت نبود فضای کافی، از سایر سرورها استفاده کرده و در زمان ممکن داده‌ها را به سرورهای صحیح تکثیر (replicate) می‌کند. این بدان معناست که اگر برخی سرورها برای مدت طولانی در حالت مشغول باشند، ممکن است ایجاد چانک‌های جدید با کلاس‌های ذخیره‌سازی خاص ممکن نباشد و چانک‌های در معرض خطر (کمتر از حد نصاب / undergoal) آن کلاس‌ها به دلیل تاخیر در تکثیر در معرض خطر از دست رفتن کامل باشند.

در حالت STRICT، هنگام نوشتن یک فایل جدید، در صورت نبود فضای کافی روی سرورهای مشخص‌شده برای ایجاد چانک، سامانه خطای نبود فضا (ENOSPC) برمی‌گرداند. سامانه همچنان برای سرورهای با بار بیش از حد منتظر می‌ماند. تکثیرهای چانک‌های در معرض خطر (undergoal) در صورت نبود فضا روی سرورهای منطبق انجام نخواهد شد. این به معنای ریسک بالای از دست رفتن داده‌ها در صورت پر شدن دائمی سرورهای دارای برخی برچسب‌ها است!

در حالت LOOSE، سامانه در صورت بار بیش از حد یا نبود فضا روی سرورها بلافاصله از سایر سرورها استفاده کرده و در صورت فراهم شدن شرایط داده‌ها را به سرورهای صحیح تکثیر می‌کند. هیچ تاخیر یا خطایی هنگام ایجاد فایل رخ نمی‌دهد و تکثیرهای undergoal همیشه در اسرع وقت انجام می‌شوند.

جدول زیر رفتار حالت‌ها را برای چانک‌های ذخیره‌شده در قالب کپی خلاصه می‌کند:

برای چانک‌های ذخیره‌شده در قالب EC، این ۳ حالت به شرح زیر عمل می‌کنند:

به‌طور کلی، چانک‌ها تنها زمانی از قالب کپی به قالب EC تبدیل می‌شوند که سرورهای کافی در سامانه برای ذخیره ایمن تمام قطعات قالب EC وجود داشته باشد. برای قالب EC @N+X، که در آن N تعداد قطعات داده (۴ یا ۸) و X تعداد قطعات پاریتی (۱ در نسخه CE یا ۱ تا ۹ در نسخه PRO) است، شرایط عمومی عبارتند از:
- حداقل N+2X چانک‌سرور برای تبدیل چانک‌های جدید از قالب کپی به قالب EC
- حداقل N+X چانک‌سرور برای حفظ چانک‌هایی که در حال حاضر در قالب EC هستند
- اگر کمتر از N+X سرور وجود داشته باشد، تمام چانک‌ها به قالب کپی (تعریف KEEP) بازمی‌گردند.

در حالت LOOSE سامانه ابتدا تلاش می‌کند از سرورهای منطبق با عبارت برچسب تعریف‌شده استفاده کند، اما اگر سرورهای دارای برچسب صحیح به اندازه کافی در دسترس نباشند (به دلیل شلوغی، کمبود فضا یا تعریف نشدن)، بدون توجه به برچسب از هر چانک‌سرور در دسترسی استفاده می‌کند؛ بنابراین مقادیر N+2X و N+X هنگام تصمیم‌گیری سامانه برای انتخاب قالب از میان تمام چانک‌سرورهای موجود محاسبه می‌شود. همچنین زمانی که بخشی از یک چانک در قالب EC از دست برود یا خراب شود، بازیابی آن بخش روی هر سرور در دسترسی انجام خواهد شد، چنانچه سروری با برچسب صحیح در دسترس نباشد.

مهم است به یاد داشته باشید که اگر سرورهای دارای برچسب صحیح به اندازه کافی در حالت LOOSE در دسترس نباشند، سامانه ممکن است به هر تعداد که بخواهد از سرورهای دیگر استفاده کند، نه فقط حداقل مقدار کسری.

در حالت STRICT سامانه فقط از سرورهای منطبق با عبارت برچسب تعریف‌شده استفاده می‌کند، بنابراین تنها سرورهای در دسترس یا موقتاً مشغول با برچسب صحیح برای محاسبه N+2X و N+X هنگام تصمیم‌گیری سامانه در نظر گرفته می‌شوند. زمانی که بخشی از یک چانک در قالب EC ناموجود یا خراب شود، بازیابی آن بخش تنها روی سروری با برچسب صحیح امکان‌پذیر است؛ اگر چنین سروری برای طولانی‌مدت در دسترس نباشد، این امر به خودی خود باعث بازگشت چانک به قالب کپی خواهد شد.

در حالت STANDARD رفتار سامانه هنگام تصمیم‌گیری برای تبدیل چانک جدید از قالب کپی به EC مانند حالت STRICT است (یعنی N+2X فقط از سرورهای با برچسب صحیح محاسبه می‌شود). اما برای تصمیم‌گیری درباره بازگرداندن چانک‌های موجود از EC به کپی، به تمام سرورهای در دسترس فارغ از برچسب نگاه می‌کند، بنابراین N+X مانند حالت LOOSE از تمام سرورهای موجود محاسبه می‌شود. در صورت مفقود شدن قطعات، اگر بازیابی روی سرورهای با برچسب درست ممکن نباشد، سامانه رفتار حالت LOOSE را در پیش گرفته و سعی می‌کند از هر سرور در دسترسی استفاده کند.

توجه! هنگامی که یک چانک از قالب کپی به قالب EC تبدیل می‌شود، سامانه ابتدا عملیات «تقسیم محلی» (local split) را انجام می‌دهد، بدین صورت که یک نسخه از چانک را انتخاب کرده و تمام قطعات EC لازم را روی سرور اشغال‌شده توسط همان نسخه محاسبه می‌کند. سپس این قطعات به چانک‌سرورهای مجزا و منطبق با برچسب‌های تعریف‌شده منتقل می‌شوند. اما به‌طور موقت، میان مرحله تقسیم و انتقال قطعات، این قطعات حتی در حالت STRICT ممکن است روی یک چانک‌سرور «نادرست» ثبت شوند. این امر به دلیل مکانیسم عملیات تقسیم محلی رخ می‌دهد.

زمان (TIME)

برای متغیرهای زمانی، مقدار می‌تواند به‌عنوان تعداد ثانیه‌ها یا ساعت‌ها (عدد صحیح) بسته به حداقل واحد متغیر، یا به‌عنوان یک بازه زمانی در یکی از دو قالب زیر تعریف شود:

قالب اول: #.#T که T یکی از این موارد است: s (ثانیه)، m (دقیقه)، h (ساعت)، d (روز) یا w (هفته)؛ کسرهای حداقل واحد به عدد صحیح گرد می‌شوند.

قالب دوم: #w#d#h#m#s، که هر تعداد از تعاریف را می‌توان حذف کرد، اما تعاریف باقی‌مانده باید به ترتیب باشند (بنابراین #d#m معتبر است اما #m#d نامعتبر است)؛ محدوده‌ها: s,m از ۰ تا ۵۹، h از ۰ تا ۲۳، d از ۰ تا ۶، w نامحدود است و اولین تعریف نیز همواره نامحدود است (مثلاً برای #d#h#m مقدار d نامحدود خواهد بود).

اگر حداقل واحد یک متغیر بزرگ‌تر از ثانیه باشد، واحدهای کوچک‌تر از آن پذیرفته نمی‌شوند. برای مثال، متغیری که حداقل واحد آن ساعت است، واحدهای s و m را نمی‌پذیرد.

مثال‌ها:

مقدار 1.5d معادل 1d12h و معادل 36h است.

مقدار 2.5w معادل 2w3d12h و معادل 420h است؛ مقدار 2w84h بازه زمانی معتبری نیست (زیرا h اولین تعریف نیست و محدود به ۰ تا ۲۳ است).

رفتار آرشیو (ARCHIVE BEHAVIOUR)

پرچم آرشیو چانک‌ها در طول چرخه نگهداری فایل تنظیم می‌شود، بدین معنا که زمان تا آرشیو تعیین‌شده توسط گزینه -d حداقل زمانی است که باید بگذرد تا پرچم تنظیم شود، نه زمان دقیق.

رفتار پیش‌فرض سامانه این است که وقتی پرچم آرشیو یک چانک روشن شد، خاموش نمی‌شود حتی اگر atime/ctime/mtime تغییر کند، مگر اینکه پرچم R با گزینه -o تنظیم شده باشد. نوشتن روی یک چانک همواره پرچم آرشیو آن را خاموش می‌کند.

پرچم‌های آرشیو:

C - استفاده از ctime فایل برای تعیین روشن شدن پرچم آرشیو - این پرچم پیش‌فرض است.

M - استفاده از mtime فایل برای تعیین روشن شدن پرچم آرشیو.

A - استفاده از atime فایل برای تعیین روشن شدن پرچم آرشیو.

R - بازگشت‌پذیر (reversible)؛ در صورت تغییر atime/mtime/ctime فایل، سامانه خاموش شدن پرچم آرشیو چانک‌های آن را بررسی می‌کند.

F - حالت سریع (fastmode)؛ پرچم آرشیو چانک در اسرع وقت روشن می‌شود و زمان تعیین‌شده با -d نادیده گرفته می‌شود.

P - حالت چانک‌به‌چانک (per chunk)؛ استفاده از mtime چانک برای تعیین روشن شدن پرچم آرشیو.

پرچم آرشیو را می‌توان به‌صورت دستی نیز تغییر داد. به mfsarchive(1) مراجعه کنید.

نکته: وضعیت ARCHIVE به این معنا نیست که چانک‌ها یا فایل‌ها به نحوی غیرقابل دسترسی یا مسدود برای نوشتن هستند. برچسب ARCHIVE صرفاً برای نشان دادن این است که این داده‌ها برای نگهداری طولانی‌مدت در نظر گرفته شده‌اند، برعکس وضعیت KEEP که نشان‌دهنده داده‌های «داغ» با تغییرات مکرر است. تمایز میان KEEP و ARCHIVE صرفاً برای تعریف روش فیزیکی مناسب ذخیره‌سازی داده‌ها است. از دید کاربر، فایل کاملاً در دسترس است: دسترسی‌ها، نام و دایرکتوری آن یکسان باقی می‌ماند. برای مثال، به دلیل اینکه نوشتن در حالت EC ممکن است کندتر باشد، توصیه می‌شود داده‌های داغ (KEEP) در قالب کپی ذخیره شوند و پس از مدتی به قالب EC (با اختصاص حالت ARCHIVE) تبدیل گردند. مثال دیگر انتقال خودکار داده‌های «سرد» به دیسک‌ها و سرورهای قدیمی‌تر/کندتر/ارزان‌تر با استفاده از برچسب‌های متفاوت است.

اولویت کلاس‌های ذخیره‌سازی (STORAGE CLASSES PRIORITY)

کلاس‌های ذخیره‌سازی به فایل‌ها اختصاص می‌یابند، اما به لطف مکانیسم اسنپ‌شات (به mfssnapshots(1) مراجعه کنید)، یک چانک (یک قطعه از فایل) می‌تواند متعلق به چندین فایل باشد. اگر یک چانک متعلق به چندین فایل با کلاس‌های ذخیره‌سازی متفاوت باشد، باید یک کلاس ذخیره‌سازی برای تعیین نحوه نگهداری نسخه‌های آن چانک در سامانه انتخاب شود. سامانه کلاسی با بالاترین اولویت را از میان کلاس‌های فایل‌ها انتخاب خواهد کرد.

مثال ۱: سه کلاس تعریف شده است:
ClassA با اولویت ۱۰۰
ClassB با اولویت ۲۰۶
ClassC با اولویت ۱۰۰۱

چانکی که متعلق به ۲ فایل باشد (یکی در ClassA و دیگری در ClassB)، طبق تعریف ClassB ذخیره می‌شود (اولویت بالاتر از ClassA).
چانکی که متعلق به ۳ فایل باشد (در ClassA، ClassB و ClassC)، طبق تعریف ClassC ذخیره می‌شود (اولویت بالاتر از هر دو).

اگر دو یا چند کلاس اولویت یکسانی داشته باشند، عوامل زیر به ترتیب اهمیت برای تعیین کلاس برگزیده بررسی می‌شوند:
- کلاسی با سطح افزونگی (RL) بالاتر انتخاب می‌شود (بیشترین مقدار سطح افزونگی KEEP و ARCHIVE در نظر گرفته می‌شود)،
- کلاسی که در وضعیت ARCHIVE قالب EC دارد نسبت به کلاسی بدون EC ترجیح داده می‌شود،
- کلاسی که از برچسب‌ها برای وضعیت KEEP یا ARCHIVE استفاده می‌کند نسبت به کلاس بدون برچسب ترجیح داده می‌شود،
- کلاسی که در وضعیت TRASH قالب EC دارد نسبت به کلاسی بدون EC ترجیح داده می‌شود،
- کلاسی که از برچسب‌ها برای وضعیت TRASH استفاده می‌کند نسبت به کلاس بدون برچسب ترجیح داده می‌شود،
- در صورت تساوی تمام شرایط بالا، کلاسی با شناسه کلاس (Class ID) بالاتر انتخاب می‌شود.

کلاس‌های ذخیره‌سازی از پیش تعریف‌شده (PREDEFINED STORAGE CLASSES)

یک نمونه تازه نصب‌شده از MooseFS دارای کلاس‌های پیش‌تعریف‌شده زیر خواهد بود:

2CP - فقط وضعیت KEEP تعریف شده است، نگهداری ۲ نسخه روی هر برچسبی (کلاس پیش‌فرض برای دایرکتوری ریشه /).

3CP - فقط وضعیت KEEP تعریف شده است، نگهداری ۳ نسخه روی هر برچسبی.

EC4+1 - در وضعیت KEEP نگهداری ۲ نسخه روی هر برچسب، در وضعیت ARCHIVE نگهداری چانک‌ها در قالب EC4+1 روی هر برچسب، تاخیر آرشیو ۱ روز است و با ctime فایل محاسبه می‌شود، فایل‌های کوچک‌تر از 512KiB به قالب EC تبدیل نمی‌شوند.

EC4+2 - (فقط نسخه Pro) در وضعیت KEEP نگهداری ۳ نسخه، در وضعیت ARCHIVE نگهداری در قالب EC4+2، تاخیر ۱ روز با ctime، فایل‌های کوچک‌تر از 512KiB تبدیل نمی‌شوند.

EC8+1 - در وضعیت KEEP نگهداری ۲ نسخه، در وضعیت ARCHIVE نگهداری در قالب EC8+1، تاخیر ۱ روز با ctime، فایل‌های کوچک‌تر از 512KiB تبدیل نمی‌شوند.

EC8+2 - (فقط نسخه Pro) در وضعیت KEEP نگهداری ۳ نسخه، در وضعیت ARCHIVE نگهداری در قالب EC8+2، تاخیر ۱ روز با ctime، فایل‌های کوچک‌تر از 512KiB تبدیل نمی‌شوند.

این کلاس‌ها کاملاً قابل ویرایش و حذف هستند و می‌توانند با کلاس‌های انتخابی کاربر جایگزین شوند.