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

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

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

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

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

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

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

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

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

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

توجه! اگر CHUNKS_UNIQUE_MODE در mfsmaster.cfg با مقداری غیر از 0 تعریف شده باشد، بر هرگونه تنظیمات تمایز در کلاس‌های ذخیره‌سازی اولویت خواهد داشت و آن را لغو خواهد کرد. برای اطلاعات بیشتر دربارهٔ این پارامتر به دفترچهٔ راهنمای 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 - فایل‌ها دارای دو رونوشت خواهند بود؛ یک رونوشت روی chunkserver(های) دارای برچسب A و دیگری روی chunkserver(های) دارای برچسب B ذخیره خواهد شد.

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

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

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

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

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

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

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

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

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

A,B/[RACK] - فایل‌ها دارای دو رونوشت خواهند بود؛ یک رونوشت روی chunkserver(های) دارای برچسب A و دیگری روی chunkserver(های) دارای برچسب 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 با ۴ بخش داده و ۳ بخش زوجیت نگهداری خواهند شد - همگی روی chunkserverهای دارای برچسب Z.

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

@3,S,H - فایل‌ها در قالب EC نگهداری خواهند شد؛ تعداد پیش‌فرض بخش‌های داده روی chunkserverهای دارای برچسب S و ۳ بخش زوجیت روی chunkserverهای دارای برچسب H نگهداری می‌شوند.

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

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

2A/[IP]:s - فایل‌ها باید در ۲ رونوشت نگهداری شوند، هر دو رونوشت روی کارسازهایی با برچسب A، اما هر کارساز باید IP متفاوتی داشته باشد؛ رفتار این مورد با در نظر گرفتن برچسب‌ها باید STRICT باشد. مشخص کردن اینکه هنگام عدم امکان برآورده‌سازی نیازمندی‌های برچسب (labels) یک کلاس ذخیره‌سازی (storage class) چه اقدامی باید صورت گیرد حائز اهمیت است؛ به عنوان مثال: هیچ فضای خالی در تمامی سرورهای دارای برچسب‌های لازم موجود نیست، تعداد سرورهای دارای برچسب‌های مورد نیاز کافی نیست، یا سرورهای دارای برچسب‌های لازم همگی مشغول هستند. پرسش این است که آیا سیستم باید چانک‌ها (chunks) را روی سرورهای دیگر (با برچسب‌های غیر منطبق) ایجاد کند یا خیر. این تصمیم باید توسط کاربر اتخاذ شود.

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

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

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

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

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

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

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

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

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

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

در حالت STRICT، سیستم منحصراً از سرورهایی استفاده می‌کند که با عبارت برچسب تعریف‌شده در کلاس ذخیره‌سازی مورداستفاده منطبق باشند، بنابراین هنگام تصمیم‌گیری سیستم درباره اینکه از چه قالبی برای نگهداری چانک استفاده شود، تنها سرورهای موجود یا کوتاه‌مدت مشغولِ منطبق با عبارت برچسبِ تعریف‌شده برای محاسبهٔ N+2X و N+X به کار گرفته می‌شوند. هنگامی که بخشی از یک چانک در قالب EC غیرقابل دسترس یا خراب شود، بازیابی آن بخش فقط روی سروری با برچسب «درست» امکان‌پذیر است؛ اگر چنین سروری برای مدت طولانی در دسترس نباشد (یعنی به طور کامل در دسترس نباشد یا صرفاً موقتاً مشغول نباشد)، این امر خودبه‌خود بدان معنا خواهد بود که چانک در هر صورت باید به قالب keep بازگردانده شود (اگر بخش مفقود از نوع parity/checksum باشد، چانک صرفاً با استفاده از تمام بخش‌های دادهٔ موجود به قالب copy بازمی‌گردد؛ اگر یک بخش داده مفقود شده باشد، روی یک چانک‌سرور که میزبان بخش دیگری از همان چانک است بازیابی می‌شود - که در شرایط عادی مجاز نیست - و سپس تبدیل به قالب copy بلافاصله انجام خواهد شد).

در حالت STANDARD، زمانی که سیستم باید تصمیم بگیرد آیا یک چانک جدید را از قالب copy به قالب EC تبدیل کند، همانند حالت STRICT رفتار می‌کند، یعنی N+2X در این مرحله صرفاً از روی سرورهای با برچسب‌گذاری «درست» محاسبه می‌شود. اما برای تصمیم‌گیری در این مورد که آیا چانک‌های موجود باید از قالب EC به قالب copy برگردانده شوند یا خیر، به تمام سرورهای در دسترس بدون توجه به برچسب‌هایشان نگاه می‌کند، بنابراین N+X در این مرحله، مانند حالت LOOSE، از روی تمام سرورهای موجود محاسبه می‌شود. در صورت مفقود شدن بخش‌ها، اگر بازیابی آن‌ها روی چانک‌سرورهای با برچسب‌های «درست» ممکن نباشد، سیستم رفتار حالت LOOSE را نیز در پیش می‌گیرد و تلاش می‌کند از هر سرور در دسترسی استفاده کند.

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

زمان (TIME)

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

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

قالب دوم: #w#d#h#m#s، هر تعداد از تعاریف را می‌توان حذف کرد، اما تعاریف باقی‌مانده باید به ترتیب باشند (بنابراین #d#m همچنان یک تعریف معتبر است، اما #m#d معتبر نیست)؛ محدوده‌ها: s و m از 0 تا 59، h از 0 تا 23، d از 0 تا 6، w نامحدود است و اولین تعریف نیز همواره نامحدود خواهد بود (برای نمونه برای #d#h#m مقدار d نامحدود است)

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

مثال‌ها:

1.5d همان 1d12h و برابر با 36h است

2.5w همان 2w3d12h و برابر با 420h است؛ 2w84h یک بازه زمانی معتبر نیست (h اولین تعریف نیست، بنابراین به محدودهٔ 0 تا 23 محدود می‌شود)

رفتار بایگانی (ARCHIVE BEHAVIOUR)

چانک‌ها پرچم بایگانی (archive flag) را در طول حلقهٔ نگهداری فایل (file maintenance loop) دریافت می‌کنند؛ این بدان معناست که زمانِ تا بایگانیِ تعریف‌شده توسط گزینهٔ -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 که نشان‌دهندهٔ «داغ» (hot) بودن داده‌ها و امکان تغییر مکرر آن‌ها است. بنابراین، تمایز بین وضعیت‌های KEEP و ARCHIVE صرفاً برای امکان‌پذیر ساختن تعریف مناسب شیوهٔ فیزیکی ذخیره‌سازی این داده‌ها است. از دیدگاه کاربر، فایل به همان اندازه قابل دسترسی است: مجوزها و نام یکسانی دارد و در همان دایرکتوری قرار گرفته است. برای مثال، با توجه به اینکه نوشتن در حالت EC ممکن است کُندتر باشد، پیشنهاد می‌کنیم داده‌های «داغ» (KEEP) با استفاده از رونوشت (copy) ذخیره شوند و پس از مدتی به قالب EC تغییر یابند (با تخصیص حالت ARCHIVE). مثال دیگر، انتقال خودکار داده‌های «سرد» (cold) به دیسک‌ها و چانک‌سرورهای قدیمی‌تر/کُندتر/ارزان‌تر با استفاده از برچسب‌های متفاوت است..SS "اولویت کلاس‌های ذخیره‌سازی (STORAGE CLASSES PRIORITY)"

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

مثال ۱: ۳ کلاس تعریف شده است:
ClassA با اولویت 100،
ClassB با اولویت 206،
ClassC با اولویت 1001.

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

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

مثال ۲: ۵ کلاس تعریف شده است که همگی اولویت یکسانی دارند (برای نمونه اولویت پیش‌فرض 0):
کلاس ClassA (شناسهٔ id=1) دارای ۳ نسخه در وضعیت KEEP است (RL=2)،
کلاس ClassB (شناسهٔ id=2) دارای ۲ نسخه در وضعیت KEEP و قالب EC4+1 در وضعیت ARCHIVE است (RL=1، دارای EC در ARCHIVE)،
کلاس ClassC (شناسهٔ id=3) دارای ۲ نسخه در وضعیت KEEP ذخیره‌شده بر روی برچسب‌های X است (RL=1، بدون EC در ARCHIVE، دارای برچسب در KEEP)،
کلاس ClassD (شناسهٔ id=4) دارای ۲ نسخه در وضعیت KEEP ذخیره‌شده بر روی برچسب‌های Y است (RL=1، بدون EC در ARCHIVE، دارای برچسب در KEEP)،
کلاس ClassE (شناسهٔ id=5) دارای ۲ نسخه در وضعیت KEEP است (RL=1).
همچنین کلاس ClassF تعریف شده است که دارای اولویت 77 و ۲ نسخه در وضعیت KEEP است (RL=1).

چانکی که متعلق به فایل‌هایی در کلاس‌های ClassA، ClassC و ClassE باشد، بر اساس تعریف ClassA ذخیره خواهد شد (بالاترین RL).
چانکی که متعلق به فایل‌هایی در کلاس‌های ClassB و ClassC باشد، بر اساس تعریف ClassB ذخیره خواهد شد (RL یکسان، اما ClassB دارای EC است).
چانکی که متعلق به فایل‌هایی در کلاس‌های ClassC و ClassE باشد، بر اساس تعریف ClassC ذخیره خواهد شد (RL یکسان، اما ClassC دارای برچسب است).
چانکی که متعلق به فایل‌هایی در کلاس‌های ClassC و ClassD باشد، بر اساس تعریف ClassD ذخیره خواهد شد (RL یکسان، بدون EC، هر دو دارای برچسب هستند، بنابراین شناسهٔ کلاس بالاتر انتخاب می‌شود).
چانکی که متعلق به فایل‌هایی در ۶ کلاس، از ClassA تا ClassF باشد، بر اساس تعریف ClassF ذخیره خواهد شد، زیرا این کلاس اولویت بالاتری نسبت به تمام کلاس‌های دیگر دارد (77>0).
در سامانه‌ای با این ۶ کلاس ذخیره‌سازی، ClassE هرگز برای چانکی متعلق به چندین فایل استفاده نخواهد شد؛ این کلاس دارای کمترین اولویت ممکن (0) است و هیچ شرط اضافی برای توجیه انتخاب آن وجود ندارد (کمترین RL موجود، بدون EC و بدون برچسب).

کلاس‌های ذخیره‌سازی از پیش تعریف‌شده (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 به قالب EC تبدیل نخواهند شد

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

EC8+2 - (تنها pro) در وضعیت KEEP، نگهداری ۳ نسخه روی هر برچسبی؛ در وضعیت ARCHIVE، نگهداری چانک‌ها در قالب EC8+2 روی هر برچسبی؛ تأخیر بایگانی ۱ روز است و با ctime فایل محاسبه می‌شود؛ فایل‌های کوچک‌تر از 512kiB به قالب EC تبدیل نخواهند شد

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

تا نسخهٔ 4.56.0 از MooseFS کلاس‌های از پیش تعریف‌شده متفاوت بودند. اطلاعات زیر مربوط به رفتار قدیمی MooseFS است. در نسخه‌های جدیدتر MooseFS ممکن است کلاس‌های ذکرشده در زیر در نتیجهٔ ارتقا وجود داشته باشند، اما رفتاری دقیقاً مانند کلاس‌های تعریف‌شده توسط کاربر خواهند داشت. این اطلاعات صرفاً جنبهٔ اطلاع‌رسانی دارد و در آینده از این صفحهٔ راهنما حذف خواهد شد:

(رفتار تا نسخهٔ 4.56.0) “به دلایل سازگاری، هر نمونهٔ تازه یا به‌تازگی ارتقایافته از MooseFS دارای ۹ کلاس ذخیره‌سازی از پیش تعریف‌شده است. نام‌های آن‌ها تک‌رقمی، از 1 تا 9، و تعاریف آن‌ها از * تا 9* است. آن‌ها معادل‌های اهداف (goals) عددی ساده از نسخه‌های پیشین سامانه هستند. در صورت ارتقا، تمام فایل‌هایی که پیش از ارتقا دارای هدف N بودند، اکنون دارای کلاس ذخیره‌سازی N خواهند بود. این کلاس‌ها تنها زمانی قابل تغییرند که گزینهٔ -f مشخص شده باشد. توصیه می‌شود در سامانه‌ای ارتقایافته، به‌جای تغییر کلاس‌های از پیش تعریف‌شده، کلاس‌های ذخیره‌سازی جدیدی ایجاد کرده و فایل‌ها را با ابزار mfsxchgsclass منتقل کنید. کلاس‌های از پیش تعریف‌شده را نمی‌توان حذف کرد.”.SH "مثال‌ها (EXAMPLES)"

ایجاد یک رده ذخیره‌سازی (storage class) جدید با نام «Class2Copies» با ۲ رونوشت؛ رونوشت نخست روی یکی از chunkserverها با برچسب «A» و رونوشت دوم روی یکی از chunkserverها با برچسب «B»:

mfscreatesclass -K A,B Class2Copies

ایجاد یک رده ذخیره‌سازی جدید با نام «Class3Copies». چانک‌های تازه ایجادشده (-C) با ۲ رونوشت (2*) در هر مکانی نگهداری خواهند شد. کمی پس از ایجاد، آن‌ها در ۳ رونوشت نگهداری می‌شوند (-K): رونوشت نخست روی یکی از chunkserverها با برچسب «A»، رونوشت دوم روی یکی از chunkserverها با برچسب «B» و رونوشت سوم روی هر chunkserver دیگری:

mfscreatesclass -C '2*' -K 'A,B,*' Class3Copies

ایجاد یک رده ذخیره‌سازی جدید با نام «ClassEC4_1». چانک‌ها به مدت ۲۴ ساعت پس از ایجاد فایل در ۲ رونوشت (2*) در هر مکانی ایجاد و نگهداری می‌شوند (-K). سپس در قالب EC4+1 روی هر chunkserver دلخواهی بایگانی خواهند شد (-A):

mfscreatesclass -K '2*' -A '@4+1' ClassEC4_1

تغییر رده ذخیره‌سازی «ClassEC4_1» برای بایگانی کردن چانک‌ها پس از گذشت ۴۸ ساعت از تغییر فایل (نه زمان ایجاد آن):

mfsmodifysclass -d 2d -o m ClassEC4_1

تغییر رده ذخیره‌سازی «Class3Copies» برای نگهداری چانک‌ها روی سایر chunkserverها (حالت LOOSE) در صورتی که سرورهای دارای برچسب‌های «A» و «B» بیش از حد مشغول (overloaded) باشند:

mfsmodifysclass -m l Class3Copies