.TH mfscreatesclass "1" "May 2026" "MooseFS 4.59.2-1" "این بخشی از MooseFS است"
.ss 12 0
.SH "نام (NAME)"
mfscreatesclass \- ایجاد کلاس ذخیره‌سازی جدید در سامانه فایل MooseFS
.SH "خلاصه دستور (SYNOPSIS)"
.B mfscreatesclass
[\fB\-?\fP] [\fB\-M\fP \fIنقطه_اتصال\fP]
\fB\-K\fP \fIبرچسب‌های_نگهداری\fP
[\fB\-c\fP \fIتوضیحات\fP]
[\fB\-p\fP \fIاولویت\fP]
[\fB\-g\fP \fIگروه_برون‌بری\fP]
[\fB\-a\fP \fIفقط_مدیر\fP]
[\fB\-m\fP \fIحالت_برچسب‌ها\fP]
[\fB\-o\fP \fIحالت_آرشیو\fP]
[\fB\-C\fP \fIبرچسب‌های_ایجاد\fP]
[\fB\-A\fP \fIبرچسب‌های_آرشیو\fP [\fB\-d\fP \fIتاخیر_آرشیو\fP] [\fB\-s\fP \fIحداقل_طول_فایل\fP]]
[\fB\-T\fP \fIبرچسب‌های_سطل_زباله\fP [\fB\-t\fP \fIحداقل_زمان_نگهداری_زباله\fP]]
\fIنام_کلاس_ذخیره‌سازی\fP...
.PP
.B mfsmodifysclass
[\fB\-?\fP] [\fB\-M\fP \fIنقطه_اتصال\fP]
[\fB\-c\fP \fIتوضیحات\fP]
[\fB\-p\fP \fIاولویت\fP]
[\fB\-g\fP \fIگروه_برون‌بری\fP]
[\fB\-a\fP \fIفقط_مدیر\fP]
[\fB\-m\fP \fIحالت_برچسب‌ها\fP]
[\fB\-o\fP \fIحالت_آرشیو\fP]
[\fB\-C\fP \fIبرچسب‌های_ایجاد\fP]
[\fB\-K\fP \fIبرچسب‌های_نگهداری\fP]
[\fB\-A\fP \fIبرچسب‌های_آرشیو\fP]
[\fB\-d\fP \fIتاخیر_آرشیو\fP]
[\fB\-s\fP \fIحداقل_طول_فایل\fP]
[\fB\-T\fP \fIبرچسب‌های_سطل_زباله\fP]
[\fB\-t\fP \fIحداقل_زمان_نگهداری_زباله\fP]
\fIنام_کلاس_ذخیره‌سازی\fP...
.PP
.B mfsdeletesclass
[\fB\-?\fP] [\fB\-M\fP \fIنقطه_اتصال\fP]
\fIنام_کلاس_ذخیره‌سازی\fP...
.PP
.B mfsclonesclass
[\fB\-?\fP] [\fB\-M\fP \fIنقطه_اتصال\fP]
\fIنام_کلاس_مبدأ\fP \fIنام_کلاس_مقصد\fP...
.PP
.B mfsrenamesclass
[\fB\-?\fP] [\fB\-M\fP \fIنقطه_اتصال\fP]
\fIنام_کلاس_مبدأ\fP \fIنام_کلاس_مقصد\fP
.PP
.B mfslistsclass
[\fB\-?\fP] [\fB\-M\fP \fIنقطه_اتصال\fP]
[\fB\-l\fP]
[\fB\-i\fP]
[\fIالگوی_تطبیق_نام_کلاس\fP]
.PP
.B mfsimportsclass
[\fB\-?\fP] [\fB\-M\fP \fIنقطه_اتصال\fP] [\fB\-r\fP]
[\fB\-n\fP \fIنام_فایل\fP]

.SH "توضیحات (DESCRIPTION)"
.PP
این مجموعه ابزارهایی برای مدیریت کلاس‌های ذخیره‌سازی MooseFS است.
کلاس‌های ذخیره‌سازی برای تعیین سیاست افزونگی درون کلاستر به کار می‌روند.
این کلاس‌ها بعداً با ابزارهای \fBmfssclass\fP روی اشیاء مشخص MooseFS (فایل‌ها یا پوشه‌ها) اعمال می‌شوند (به \fBmfssclass\fP(1) مراجعه کنید).
کلاس ذخیره‌سازی مجموعه‌ای نام‌گذاری‌شده از عبارات برچسب‌ها و گزینه‌های دیگر است. عبارت برچسب‌ها قالب افزونگی، سطح افزونگی مطلوب و سیاست ذخیره‌سازی مورد نظر را مشخص می‌کند.
قالب افزونگی می‌تواند نسخه‌های کپی (copies) یا کدگذاری حذفی (EC) باشد.
سطح افزونگی یا تعداد نسخه‌های کپی (از ۱ تا ۹) یا تعداد قطعات داده به‌علاوه قطعات پاریتی (4+n یا 8+n) است، بسته به قالب افزونگی تعیین‌شده.
سیاست ذخیره‌سازی از طریق کاربرد برچسب‌ها مشخص می‌کند که کدام چانک‌سرورها باید برای ذخیره فیزیکی داده‌های اختصاص‌یافته به آن کلاس ذخیره‌سازی خاص استفاده شوند.
.PP
ابزار
.B mfscreatesclass
یک کلاس ذخیره‌سازی جدید با گزینه‌های داده‌شده (توضیح‌داده‌شده در زیر) ایجاد کرده و نام آن را
\fIنام_کلاس_ذخیره‌سازی\fP می‌گذارد؛ می‌توان بیش از یک نام تعیین کرد که در این صورت چندین کلاس ذخیره‌سازی با تعریف یکسان ایجاد می‌شوند.
.PP
ابزار
.B mfsmodifysclass
گزینه‌های داده‌شده را در یک یا چند کلاس مشخص‌شده با پارامتر(های) \fIنام_کلاس_ذخیره‌سازی\fP تغییر می‌دهد.
.PP
ابزار
.B mfsdeletesclass
کلاس یا کلاس‌های مشخص‌شده با پارامتر(های) \fIنام_کلاس_ذخیره‌سازی\fP را حذف می‌کند؛ اگر هر یک از کلاس‌ها خالی نباشد (یعنی هنوز توسط اشیایی در MooseFS استفاده شود)، حذف نخواهد شد و ابزار خطا داده و پیام خطا چاپ می‌شود؛ کلاس‌های خالی در هر صورت حذف خواهند شد.
.PP
ابزار
.B mfsclonesclass
کلاس مشخص‌شده با \fIنام_کلاس_مبدأ\fP را تحت نام جدید ارائه‌شده با \fIنام_کلاس_مقصد\fP کپی می‌کند.
.PP
ابزار
.B mfsrenamesclass
نام یک کلاس را از \fIنام_کلاس_مبدأ\fP به \fIنام_کلاس_مقصد\fP تغییر می‌دهد.
.PP
ابزار
.B mfslistsclass
تمام کلاس‌ها را فهرست می‌کند.
.PP
ابزار
.B mfsimportsclass
تعاریف کلاس‌های ذخیره‌سازی را از ورودی استاندارد (stdin) یا یک فایل وارد (ایمپورت) کرده و آن‌ها را ایجاد می‌کند؛ قالب ورودی باید با خروجی \fBmfslistsclass \-l\fP یکسان باشد.

.SH "گزینه‌ها (OPTIONS)"
.PP
.B \-C
پارامتر اختیاری، به سامانه اعلام می‌کند که هنگام ایجاد یک قطعه داده (چانک)، داده‌ها بلافاصله پس از ایجاد ابتدا روی کدام چانک‌سرورهای تعریف‌شده با عبارت \fICREATE_LABELS\fP نوشته شوند؛ در صورتی که این پارامتر برای یک کلاس تعیین نشود، چانک‌سرورهای \fIKEEP_LABELS\fP استفاده خواهند شد.
.PP
.B \-K
پارامتر اجباری، به سامانه اعلام می‌کند که چانک(ها) همواره باید روی کدام چانک‌سرورهای تعریف‌شده با عبارت \fIKEEP_LABELS\fP نگهداری شوند، مگر در شرایط خاص مانند ایجاد، آرشیو و حذف (انتقال به سطل زباله)، در صورت تعریف.
.PP
.B \-A
پارامتر اختیاری، به سامانه اعلام می‌کند که چانک(ها) برای اهداف آرشیو روی کدام چانک‌سرورهای تعریف‌شده با عبارت \fIARCH_LABELS\fP نگهداری شوند؛ سامانه زمانی یک چانک را به‌عنوان آرشیو در نظر می‌گیرد که atime/mtime/ctime (تعیین‌شده با \fB\-o\fP) فایلی که چانک به آن تعلق دارد، قدیمی‌تر از تعداد ساعات تعیین‌شده با گزینه \fB\-d\fP باشد؛ همچنین بخش \fBARCHIVE BEHAVIOUR\fP را در ادامه ببینید.
.PP
.B \-d
پارامتر اختیاری که مشخص می‌کند پس از گذشت چه مدت زمانی از atime/mtime/ctime (تعیین‌شده با \fB\-o\fP)، یک فایل (و چانک‌های آن) به‌عنوان آرشیو در نظر گرفته شوند؛ حداقل واحد ساعت است، مقدار پیش‌فرض ۲۴، برای نحوه قالب‌بندی مقدار به بخش \fBTIME\fP مراجعه کنید.
.PP
.B \-o
پارامتر اختیاری که پرچم‌های آرشیو را تعیین می‌کند:
\fBC\fP \- ctime، \fBM\fP \- mtime، \fBA\fP \- atime، \fBR\fP \- بازگشت‌پذیر (reversible)، \fBF\fP \- حالت سریع (fastmode)، \fBP\fP \- به‌ازای هر چانک (per chunk)؛
مقدار پیش‌فرض \fBC\fP است؛ برای جزئیات به بخش \fBARCHIVE BEHAVIOUR\fP در زیر مراجعه فرمایید.
.PP
.B \-s
پارامتر اختیاری که حداقل طول فایل بر حسب بایت را برای قابلیت آرشیو شدن مشخص می‌کند؛ پیش‌فرض ۰ است.
.PP
.B \-T
پارامتر اختیاری، به سامانه اعلام می‌کند که چانک(های) فایل‌های موجود در سطل زباله (Trash) باید روی کدام چانک‌سرورهای تعریف‌شده با عبارت \fITRASH_LABELS\fP نگهداری شوند؛ همچنین \fB\-t\fP را ببینید.
.PP
.B \-t
پارامتر اختیاری که مشخص می‌کند چه مدت زمان از ماندن در سطل زباله باید باقی مانده باشد تا سامانه الگوی تعریف‌شده در \fB\-T\fP را برای یک چانک به کار گیرد؛ حداقل واحد ساعت است، پیش‌فرض ۰، برای قالب‌بندی مقدار به بخش \fBTIME\fP مراجعه کنید.
.PP
.B \-c
پارامتر اختیاری که توضیحات کلاس را برای راحتی کاربر مشخص می‌کند (یک رشته، حداکثر طول ۲۵۵ بایت).
.PP
.B \-p
پارامتر اختیاری که اولویت کلاس را مشخص می‌کند؛ پیش‌فرض ۰ است، به بخش \fBSTORAGE CLASSES PRIORITY\fP مراجعه کنید.
.PP
.B \-g
پارامتر اختیاری که گروه برون‌بری کلاس را مشخص می‌کند؛ مقادیر مجاز ۰ تا ۱۵ است، پیش‌فرض ۰؛ برای توضیحات به \fBmfsexports.cfg\fP(5) مراجعه فرمایید.
.PP
.B \-a
می‌تواند ۰ یا ۱ باشد و نشان می‌دهد که آیا کلاس ذخیره‌سازی برای همگان در دسترس است (۰) یا فقط برای مدیر سیستم (۱).
.PP
.B \-m
حالت برچسب مورد استفاده؛ مقادیر ممکن عبارتند از: \fBl\fP (یا \fBL\fP، \fBloose\fP، \fBLoose\fP، \fBLOOSE\fP) برای حالت آزاد (LOOSE)، \fBd\fP (یا \fBD\fP، \fBstd\fP، \fBStd\fP، \fBSTD\fP) برای حالت استاندارد (STANDARD) و \fBs\fP (یا \fBS\fP، \fBstrict\fP، \fBStrict\fP، \fBSTRICT\fP) برای حالت سخت‌گیرانه (STRICT)؛ اگر حالتی تعریف نشود، حالت STANDARD فرض می‌شود؛ رفتار حالت‌های برچسب در زیر در بخش \fBLABEL MODES\fP شرح داده شده است.
.PP
.B \-l
علاوه بر نام کلاس‌های ذخیره‌سازی موجود، تعاریف آن‌ها را نیز فهرست می‌کند.
.PP
.B \-i
تطبیق نام کلاس ذخیره‌سازی بدون حساسیت به بزرگی و کوچکی حروف.
.PP
.B \-r
جایگزینی (بازنویسی) کلاس‌های موجود هنگام وارد کردن کلاس‌های ذخیره‌سازی.
.PP
.B \-n
استفاده از نام فایل داده‌شده به‌عنوان منبع تعاریف کلاس‌های ذخیره‌سازی برای وارد کردن، به‌جای stdin.
.PP
.B \-M
نقطه اتصال \fBMooseFS\fP؛ در صورتی که ابزار درون دایرکتوری متصل‌شده \fBMooseFS\fP اجرا شود یا \fBMooseFS\fP در مسیر /mnt/mfs/ متصل باشد، نیازی به تعیین آن نیست.
.PP
.B \-?
نمایش پیام کوتاه نحوه استفاده و راهنما.

.SH "نکات (NOTES)"

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

برچسب‌ها حروفی هستند (A-Z \- ۲۶ حرف) که می‌توانند به چانک‌سرورها اختصاص یابند. هر چانک‌سرور می‌تواند چندین برچسب (تا ۲۶ برچسب) داشته باشد. برچسب‌ها در فایل mfschunkserver.cfg تعریف می‌شوند؛ برای اطلاعات بیشتر به صفحه راهنمای مربوطه مراجعه کنید.
.PP
عبارت برچسب‌ها مجموعه‌ای از زیرعبارت‌ها است که با کاما از یکدیگر جدا شده‌اند. برای نسخه‌های کامل (کپی)، هر زیرعبارت الگوی ذخیره‌سازی یک نسخه از فایل را مشخص می‌کند. زیرعبارت می‌تواند شامل یک ستاره (*) یا یک الگوی برچسب باشد. الگوی برچسب می‌تواند یک برچسب یا عبارتی شامل جمع‌ها، ضرب‌ها، نقیض‌ها و پرانتزها باشد. جمع به این معنی است که فایل می‌تواند روی هر چانک‌سروری که با هر یک از عناصر جمع مطابقت دارد ذخیره شود (یا منطقی / OR). ضرب به این معنی است که فایل فقط روی چانک‌سروری ذخیره می‌شود که با تمام عناصر مطابقت داشته باشد (و منطقی / AND). ستاره یعنی هر چانک‌سروری. نقیض یعنی هر چانک‌سروری به جز چانک‌سروری که با زیرعبارت نفی‌شده تطبیق دارد. زیرعبارت‌های یکسان را می‌توان با افزودن یک عدد در جلوی آن خلاصه کرد به‌جای اینکه چندین بار تکرار شوند.
.PP
برای کدگذاری حذفی (EC)، عبارت برچسب با علامت \fB@\fP شروع می‌شود، به دنبال آن تعداد قطعات داده، سپس علامت \fB+\fP و عددی که مشخص می‌کند چانک باید چند قطعه پاریتی داشته باشد. تعداد مجاز قطعات داده \fB4\fP یا \fB8\fP است. تعداد مجاز قطعات پاریتی \fB1\fP (در نسخه CE) یا \fB1\fP تا \fB9\fP (در نسخه PRO) است. بنابراین، برای مثال، \fB@4+1\fP یعنی EC با ۴ قطعه داده و ۱ قطعه پاریتی، و \fB@8+3\fP یعنی EC با ۸ قطعه داده و ۳ قطعه پاریتی. اگر تعداد قطعات داده حذف شود، مستر از مقدار پیش‌فرض تعریف‌شده توسط DEFAULT_EC_DATA_PARTS استفاده می‌کند \- به \fBmfsmaster.cfg\fP(5) مراجعه کنید. در این حالت \fB@2\fP به معنی \fB@8+2\fP یا \fB@4+2\fP خواهد بود. سپس حداکثر دو زیرعبارت می‌تواند به دنبال آن بیاید که با کاما جدا شده‌اند. اگر تنها یکی وجود داشته باشد، تعیین می‌کند که تمام قطعات کجا باید نگهداری شوند. اگر هر دو وجود داشته باشند، زیرعبارت اول تعیین می‌کند قطعات داده کجا نگهداری شوند و زیرعبارت دوم تعیین می‌کند قطعات پاریتی کجا نگهداری شوند.
.PP
عبارت برچسب‌ها می‌تواند یک عبارت برچسب معمولی یا عبارت برچسب EC باشد (یعنی عبارت برچسب EC نمی‌تواند یک زیرعبارت باشد). عبارت برچسب EC تنها می‌تواند به‌جای \fBARCHIVE_LABELS\fP یا \fBTRASH_LABELS\fP در تعریف کلاس ذخیره‌سازی استفاده شود، اما عبارت برچسب معمولی در هر جایی قابل استفاده است.
.PP
در انتهای هر عبارت برچسب می‌توان یک یا دو اطلاعات تکمیلی اضافه کرد که با یک جداکننده ویژه تفکیک می‌شوند. اولین افزونه ممکن، افزونه تمایز (distinguish) است و جداکننده آن علامت اسلش (/) است. دومی بازنویسی حالت برچسب‌ها است که با علامت دونقطه (:) جدا می‌شود.
.PP
افزونه تمایز می‌تواند فهرستی از برچسب‌ها یا یکی از رشته‌های ویژه زیر باشد:
.PP
[IP] یا [I] \- تمایز بر اساس شماره IP
.PP
[RACK] یا [R] \- تمایز بر اساس رک (RACK)، همان‌طور که در توپولوژی تعریف شده است؛ به \fBmfstopology.cfg\fP(5) مراجعه کنید.
.PP
در صورت وجود، بخش تمایز به سامانه می‌فهماند که باید سعی کند نسخه‌های کامل را طوری توزیع کند که هر نسخه روی یک برچسب متفاوت از فهرست یا روی چانک‌سروری با نشانی IP متفاوت یا از رکی متفاوت باشد. برای EC، بخش تمایز در حال حاضر نادیده گرفته می‌شود.
.PP
\fBتوجه!\fP اگر \fBCHUNKS_UNIQUE_MODE\fP در \fBmfsmaster.cfg\fP با مقداری غیر از ۰ تعریف شده باشد، هرگونه تنظیم تمایز در کلاس‌های ذخیره‌سازی را لغو خواهد کرد. برای اطلاعات بیشتر در مورد این پارامتر به راهنمای \fBmfsmaster.cfg\fP(5) مراجعه کنید.
.PP
افزونه بازنویسی حالت برچسب‌ها می‌تواند یکی از سه نویسه باشد: \fBd\fP (یا \fBD\fP یا به شکل رشته \fBstd\fP، \fBStd\fP، \fBSTD\fP)، \fBs\fP (یا \fBS\fP یا به شکل رشته \fBstrict\fP، \fBStrict\fP، \fBSTRICT\fP) یا \fBl\fP (یا \fBL\fP یا به شکل رشته \fBloose\fP، \fBLoose\fP، \fBLOOSE\fP) و این بدان معناست که حالت برچسب STANDARD، STRICT یا LOOSE به ترتیب باید تنها روی همین یک عبارت برچسب اعمال شود. برای توضیحات درباره حالت‌های برچسب به بخش LABEL MODES مراجعه کنید.
.PP
یک یا هر دو افزونه می‌توانند برای هر عبارت برچسب وجود داشته باشند؛ هر کدام باید با جداکننده خود آغاز شوند و در صورت وجود هر دو، ترتیب باید حفظ شود، یعنی افزونه تمایز ابتدا و افزونه حالت برچسب دوم باشد.
.PP
مثال‌هایی از عبارات برچسب‌ها:
.PP
\fBA,B\fP \- فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی چانک‌سرور(های) دارای برچسب \fBA\fP و دیگری روی چانک‌سرور(های) دارای برچسب \fBB\fP ذخیره می‌شود.
.PP
\fBA,*\fP \- فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی چانک‌سرور(های) دارای برچسب \fBA\fP و دیگری روی هر چانک‌سروری ذخیره می‌شود.
.PP
\fBA,!A\fP \- فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی چانک‌سرور(های) دارای برچسب \fBA\fP و دیگری روی هر چانک‌سروری که فاقد برچسب \fBA\fP باشد ذخیره می‌شود.
.PP
\fB*,*\fP \- فایل‌ها دارای دو نسخه خواهند بود که روی هر چانک‌سروری (متفاوت برای هر نسخه) ذخیره می‌شوند.
.PP
\fBAB,C+D+E\fP \- فایل‌ها دارای دو نسخه خواهند بود؛ یک نسخه روی هر چانک‌سروری که هر دو برچسب \fBA\fP و \fBB\fP را دارد (ضرب برچسب‌ها) و دیگری روی هر چانک‌سروری که برچسب \fBC\fP یا \fBD\fP یا \fBE\fP را دارد (جمع برچسب‌ها) ذخیره می‌شود.
.PP
\fBA,B[X+Y],C[X+Y]\fP \- فایل‌ها دارای سه نسخه خواهند بود؛ یک نسخه روی چانک‌سرور با برچسب \fBA\fP، نسخه دوم روی چانک‌سروری با برچسب \fBB\fP و یکی از برچسب‌های \fBX\fP یا \fBY\fP، و نسخه سوم روی چانک‌سروری با برچسب \fBC\fP و یکی از برچسب‌های \fBX\fP یا \fBY\fP ذخیره می‌شود.
.PP
عبارت \fB2A\fP معادل عبارت \fBA,A\fP است.
.PP
عبارت \fBA,3BC\fP معادل عبارت \fBA,BC,BC,BC\fP است.
.PP
عبارت \fB2\fP معادل \fB2*\fP و معادل \fB*,*\fP است.
.PP
\fB3*/[IP]\fP \- فایل‌ها ۳ نسخه خواهند داشت و هر نسخه روی چانک‌سروری با نشانی IP متفاوت نگهداری می‌شود.
.PP
\fBA,B/[RACK]\fP \- فایل‌ها ۲ نسخه خواهند داشت؛ یک نسخه روی چانک‌سرور با برچسب \fBA\fP و دیگری روی چانک‌سرور با برچسب \fBB\fP در رکی متفاوت از نسخه دیگر ذخیره می‌شود.
.PP
\fBS,H,H/ABX-Z\fP \- فایل‌ها ۳ نسخه خواهند داشت؛ یکی روی سرور با برچسب \fBS\fP، دو تا روی سرورهای با برچسب \fBH\fP، اما هر نسخه روی سروری با برچسب متفاوت از مجموعه \fBA\fP، \fBB\fP، \fBX\fP، \fBY\fP، \fBZ\fP خواهد بود.
.PP
\fB@4+1\fP \- فایل‌ها در قالب EC نگهداری می‌شوند: ۴ قطعه داده و ۱ قطعه پاریتی.
.PP
\fB@8+3\fP \- فایل‌ها در قالب EC نگهداری می‌شوند: ۸ قطعه داده و ۳ قطعه پاریتی.
.PP
\fB@2\fP \- فایل‌ها در قالب EC نگهداری می‌شوند: تعداد پیش‌فرض قطعات داده، ۲ قطعه پاریتی.
.PP
\fB@4+3,Z\fP \- فایل‌ها در قالب EC نگهداری می‌شوند: ۴ قطعه داده و ۳ قطعه پاریتی \- همگی روی چانک‌سرورهای با برچسب \fBZ\fP.
.PP
\fB@2,A(X+Y)\fP \- فایل‌ها در قالب EC نگهداری می‌شوند: تعداد پیش‌فرض قطعات داده، ۲ قطعه پاریتی؛ تمام قطعات روی چانک‌سرورهایی با برچسب \fBA\fP و یکی از \fBX\fP یا \fBY\fP نگهداری می‌شوند.
.PP
\fB@3,S,H\fP \- فایل‌ها در قالب EC نگهداری می‌شوند: تعداد پیش‌فرض قطعات داده روی سرورهای با برچسب \fBS\fP، و ۳ قطعه پاریتی روی سرورهای با برچسب \fBH\fP نگهداری می‌شوند.
.PP
\fBAB,AC:l\fP \- فایل‌ها در قالب کپی نگهداری می‌شوند؛ یک نسخه روی سرور با برچسب‌های \fBA\fP و \fBB\fP، نسخه دوم روی سرور با برچسب‌های \fBA\fP و \fBC\fP و رفتار این عبارت در حالت \fBLOOSE\fP خواهد بود.
.PP
\fB@4+2,X,Y:s\fP \- فایل‌ها در قالب EC نگهداری می‌شوند؛ ۴ قطعه داده روی سرورهای با برچسب \fBX\fP، ۲ قطعه پاریتی روی سرورهای با برچسب \fBY\fP و رفتار این عبارت در حالت \fBSTRICT\fP خواهد بود.
.PP
\fB2A/[IP]:s\fP \- فایل‌ها باید در ۲ نسخه نگهداری شوند، هر دو نسخه روی سرورهای با برچسب A، اما هر سرور باید IP متفاوتی داشته باشد و رفتار آن در تطبیق برچسب‌ها \fBSTRICT\fP باشد.

.SS "حالت‌های برچسب (LABEL MODES)"
تعیین اینکه در صورت عدم امکان برآورده ساختن الزامات برچسب‌های یک کلاس ذخیره‌سازی چه باید کرد، بسیار مهم است؛ یعنی در شرایطی مانند: نبود فضای کافی روی تمام سرورهای دارای برچسب‌های لازم، نبود تعداد کافی سرور با برچسب‌های لازم، یا مشغول بودن تمام سرورهای دارای برچسب‌های لازم.
مسئله این است که آیا سامانه باید چانک‌ها را روی سرورهای دیگر (با برچسب‌های نامنطبق) ایجاد کند یا خیر. این تصمیم باید توسط کاربر اتخاذ شود.
.PP
سه حالت کاری وجود دارد: STANDARD، LOOSE و STRICT. این حالت‌ها بسته به اینکه چانک در قالب کپی یا EC ذخیره شود، به دلیل ماهیت و الگوریتم‌های متفاوت هر قالب، عملکرد متفاوتی دارند.
.PP
برای قالب کپی (copies)، این ۳ حالت به شرح زیر عمل می‌کنند:
.PP
در حالت STANDARD در صورت بار بیش از حد سرورها (overloaded)، سامانه منتظر آن‌ها می‌ماند، اما در صورت نبود فضای کافی، از سایر سرورها استفاده کرده و در زمان ممکن داده‌ها را به سرورهای صحیح تکثیر (replicate) می‌کند. این بدان معناست که اگر برخی سرورها برای مدت طولانی در حالت مشغول باشند، ممکن است ایجاد چانک‌های جدید با کلاس‌های ذخیره‌سازی خاص ممکن نباشد و چانک‌های در معرض خطر (کمتر از حد نصاب / undergoal) آن کلاس‌ها به دلیل تاخیر در تکثیر در معرض خطر از دست رفتن کامل باشند.
.PP
در حالت STRICT، هنگام نوشتن یک فایل جدید، در صورت نبود فضای کافی روی سرورهای مشخص‌شده برای ایجاد چانک، سامانه خطای نبود فضا (ENOSPC) برمی‌گرداند. سامانه همچنان برای سرورهای با بار بیش از حد منتظر می‌ماند. تکثیرهای چانک‌های در معرض خطر (undergoal) در صورت نبود فضا روی سرورهای منطبق انجام نخواهد شد. این به معنای ریسک بالای از دست رفتن داده‌ها در صورت پر شدن دائمی سرورهای دارای برخی برچسب‌ها است!
.PP
در حالت LOOSE، سامانه در صورت بار بیش از حد یا نبود فضا روی سرورها بلافاصله از سایر سرورها استفاده کرده و در صورت فراهم شدن شرایط داده‌ها را به سرورهای صحیح تکثیر می‌کند. هیچ تاخیر یا خطایی هنگام ایجاد فایل رخ نمی‌دهد و تکثیرهای undergoal همیشه در اسرع وقت انجام می‌شوند.
.PP
جدول زیر رفتار حالت‌ها را برای چانک‌های ذخیره‌شده در قالب کپی خلاصه می‌کند:
.TS
tab(@); llll.
@STANDARD@STRICT@LOOSE
CREATE - OVERLOADED@WAIT@WAIT@WRITE ANY
CREATE - NO SPACE@WRITE ANY@ENOSPC@WRITE ANY
REPLICATE - OVERLOADED@WAIT@WAIT@WRITE ANY
REPLICATE - NO SPACE@WRITE ANY@NO COPY@WRITE ANY
.TE
.PP
برای چانک‌های ذخیره‌شده در قالب EC، این ۳ حالت به شرح زیر عمل می‌کنند:
.PP
به‌طور کلی، چانک‌ها تنها زمانی از قالب کپی به قالب EC تبدیل می‌شوند که سرورهای کافی در سامانه برای ذخیره ایمن تمام قطعات قالب EC وجود داشته باشد. برای قالب EC @N+X، که در آن N تعداد قطعات داده (۴ یا ۸) و X تعداد قطعات پاریتی (۱ در نسخه CE یا ۱ تا ۹ در نسخه PRO) است، شرایط عمومی عبارتند از:
.br
\- حداقل N+2X چانک‌سرور برای تبدیل چانک‌های جدید از قالب کپی به قالب EC
.br
\- حداقل N+X چانک‌سرور برای حفظ چانک‌هایی که در حال حاضر در قالب EC هستند
.br
\- اگر کمتر از N+X سرور وجود داشته باشد، تمام چانک‌ها به قالب کپی (تعریف KEEP) بازمی‌گردند.
.PP
در حالت LOOSE سامانه ابتدا تلاش می‌کند از سرورهای منطبق با عبارت برچسب تعریف‌شده استفاده کند، اما اگر سرورهای دارای برچسب صحیح به اندازه کافی در دسترس نباشند (به دلیل شلوغی، کمبود فضا یا تعریف نشدن)، بدون توجه به برچسب از هر چانک‌سرور در دسترسی استفاده می‌کند؛ بنابراین مقادیر N+2X و N+X هنگام تصمیم‌گیری سامانه برای انتخاب قالب از میان تمام چانک‌سرورهای موجود محاسبه می‌شود. همچنین زمانی که بخشی از یک چانک در قالب EC از دست برود یا خراب شود، بازیابی آن بخش روی هر سرور در دسترسی انجام خواهد شد، چنانچه سروری با برچسب صحیح در دسترس نباشد.
.PP
مهم است به یاد داشته باشید که اگر سرورهای دارای برچسب صحیح به اندازه کافی در حالت LOOSE در دسترس نباشند، سامانه ممکن است به هر تعداد که بخواهد از سرورهای دیگر استفاده کند، نه فقط حداقل مقدار کسری.
.PP
در حالت STRICT سامانه فقط از سرورهای منطبق با عبارت برچسب تعریف‌شده استفاده می‌کند، بنابراین تنها سرورهای در دسترس یا موقتاً مشغول با برچسب صحیح برای محاسبه N+2X و N+X هنگام تصمیم‌گیری سامانه در نظر گرفته می‌شوند. زمانی که بخشی از یک چانک در قالب EC ناموجود یا خراب شود، بازیابی آن بخش تنها روی سروری با برچسب صحیح امکان‌پذیر است؛ اگر چنین سروری برای طولانی‌مدت در دسترس نباشد، این امر به خودی خود باعث بازگشت چانک به قالب کپی خواهد شد.
.PP
در حالت STANDARD رفتار سامانه هنگام تصمیم‌گیری برای تبدیل چانک جدید از قالب کپی به EC مانند حالت STRICT است (یعنی N+2X فقط از سرورهای با برچسب صحیح محاسبه می‌شود). اما برای تصمیم‌گیری درباره بازگرداندن چانک‌های موجود از EC به کپی، به تمام سرورهای در دسترس فارغ از برچسب نگاه می‌کند، بنابراین N+X مانند حالت LOOSE از تمام سرورهای موجود محاسبه می‌شود. در صورت مفقود شدن قطعات، اگر بازیابی روی سرورهای با برچسب درست ممکن نباشد، سامانه رفتار حالت LOOSE را در پیش گرفته و سعی می‌کند از هر سرور در دسترسی استفاده کند.
.PP
\fBتوجه!\fP هنگامی که یک چانک از قالب کپی به قالب EC تبدیل می‌شود، سامانه ابتدا عملیات «تقسیم محلی» (local split) را انجام می‌دهد، بدین صورت که یک نسخه از چانک را انتخاب کرده و تمام قطعات EC لازم را روی سرور اشغال‌شده توسط همان نسخه محاسبه می‌کند. سپس این قطعات به چانک‌سرورهای مجزا و منطبق با برچسب‌های تعریف‌شده منتقل می‌شوند. اما به‌طور موقت، میان مرحله تقسیم و انتقال قطعات، این قطعات حتی در حالت STRICT ممکن است روی یک چانک‌سرور «نادرست» ثبت شوند. این امر به دلیل مکانیسم عملیات تقسیم محلی رخ می‌دهد.

.SS "زمان (TIME)"
.PP
برای متغیرهای زمانی، مقدار می‌تواند به‌عنوان تعداد ثانیه‌ها یا ساعت‌ها (عدد صحیح) بسته به حداقل واحد متغیر، یا به‌عنوان یک بازه زمانی در یکی از دو قالب زیر تعریف شود:
.PP
قالب اول: #.#T که T یکی از این موارد است: s (ثانیه)، m (دقیقه)، h (ساعت)، d (روز) یا w (هفته)؛ کسرهای حداقل واحد به عدد صحیح گرد می‌شوند.
.PP
قالب دوم: #w#d#h#m#s، که هر تعداد از تعاریف را می‌توان حذف کرد، اما تعاریف باقی‌مانده باید به ترتیب باشند (بنابراین #d#m معتبر است اما #m#d نامعتبر است)؛ محدوده‌ها: s,m از ۰ تا ۵۹، h از ۰ تا ۲۳، d از ۰ تا ۶، w نامحدود است و اولین تعریف نیز همواره نامحدود است (مثلاً برای #d#h#m مقدار d نامحدود خواهد بود).
.PP
اگر حداقل واحد یک متغیر بزرگ‌تر از ثانیه باشد، واحدهای کوچک‌تر از آن پذیرفته نمی‌شوند. برای مثال، متغیری که حداقل واحد آن ساعت است، واحدهای s و m را نمی‌پذیرد.
.PP
مثال‌ها:
.PP
مقدار 1.5d معادل 1d12h و معادل 36h است.
.PP
مقدار 2.5w معادل 2w3d12h و معادل 420h است؛ مقدار 2w84h بازه زمانی معتبری نیست (زیرا h اولین تعریف نیست و محدود به ۰ تا ۲۳ است).

.SS "رفتار آرشیو (ARCHIVE BEHAVIOUR)"
پرچم آرشیو چانک‌ها در طول چرخه نگهداری فایل تنظیم می‌شود، بدین معنا که زمان تا آرشیو تعیین‌شده توسط گزینه \fB\-d\fP حداقل زمانی است که باید بگذرد تا پرچم تنظیم شود، نه زمان دقیق.
.PP
رفتار پیش‌فرض سامانه این است که وقتی پرچم آرشیو یک چانک روشن شد، خاموش نمی‌شود حتی اگر atime/ctime/mtime تغییر کند، مگر اینکه پرچم R با گزینه \fB\-o\fP تنظیم شده باشد. نوشتن روی یک چانک همواره پرچم آرشیو آن را خاموش می‌کند.
.PP
پرچم‌های آرشیو:
.PP
C \- استفاده از ctime فایل برای تعیین روشن شدن پرچم آرشیو \- این پرچم پیش‌فرض است.
.PP
M \- استفاده از mtime فایل برای تعیین روشن شدن پرچم آرشیو.
.PP
A \- استفاده از atime فایل برای تعیین روشن شدن پرچم آرشیو.
.PP
R \- بازگشت‌پذیر (reversible)؛ در صورت تغییر atime/mtime/ctime فایل، سامانه خاموش شدن پرچم آرشیو چانک‌های آن را بررسی می‌کند.
.PP
F \- حالت سریع (fastmode)؛ پرچم آرشیو چانک در اسرع وقت روشن می‌شود و زمان تعیین‌شده با \fB\-d\fP نادیده گرفته می‌شود.
.PP
P \- حالت چانک‌به‌چانک (per chunk)؛ استفاده از mtime چانک برای تعیین روشن شدن پرچم آرشیو.
.PP
پرچم آرشیو را می‌توان به‌صورت دستی نیز تغییر داد. به \fBmfsarchive\fP(1) مراجعه کنید.
.PP
نکته: وضعیت ARCHIVE به این معنا نیست که چانک‌ها یا فایل‌ها به نحوی غیرقابل دسترسی یا مسدود برای نوشتن هستند. برچسب ARCHIVE صرفاً برای نشان دادن این است که این داده‌ها برای نگهداری طولانی‌مدت در نظر گرفته شده‌اند، برعکس وضعیت KEEP که نشان‌دهنده داده‌های «داغ» با تغییرات مکرر است. تمایز میان KEEP و ARCHIVE صرفاً برای تعریف روش فیزیکی مناسب ذخیره‌سازی داده‌ها است. از دید کاربر، فایل کاملاً در دسترس است: دسترسی‌ها، نام و دایرکتوری آن یکسان باقی می‌ماند. برای مثال، به دلیل اینکه نوشتن در حالت EC ممکن است کندتر باشد، توصیه می‌شود داده‌های داغ (KEEP) در قالب کپی ذخیره شوند و پس از مدتی به قالب EC (با اختصاص حالت ARCHIVE) تبدیل گردند. مثال دیگر انتقال خودکار داده‌های «سرد» به دیسک‌ها و سرورهای قدیمی‌تر/کندتر/ارزان‌تر با استفاده از برچسب‌های متفاوت است.

.SS "اولویت کلاس‌های ذخیره‌سازی (STORAGE CLASSES PRIORITY)"
.PP
کلاس‌های ذخیره‌سازی به فایل‌ها اختصاص می‌یابند، اما به لطف مکانیسم اسنپ‌شات (به \fBmfssnapshots\fP(1) مراجعه کنید)، یک چانک (یک قطعه از فایل) می‌تواند متعلق به چندین فایل باشد. اگر یک چانک متعلق به چندین فایل با کلاس‌های ذخیره‌سازی متفاوت باشد، باید یک کلاس ذخیره‌سازی برای تعیین نحوه نگهداری نسخه‌های آن چانک در سامانه انتخاب شود. سامانه کلاسی با بالاترین اولویت را از میان کلاس‌های فایل‌ها انتخاب خواهد کرد.
.PP
مثال ۱: سه کلاس تعریف شده است:
.br
ClassA با اولویت ۱۰۰
.br
ClassB با اولویت ۲۰۶
.br
ClassC با اولویت ۱۰۰۱
.PP
چانکی که متعلق به ۲ فایل باشد (یکی در ClassA و دیگری در ClassB)، طبق تعریف ClassB ذخیره می‌شود (اولویت بالاتر از ClassA).
.br
چانکی که متعلق به ۳ فایل باشد (در ClassA، ClassB و ClassC)، طبق تعریف ClassC ذخیره می‌شود (اولویت بالاتر از هر دو).
.PP
اگر دو یا چند کلاس اولویت یکسانی داشته باشند، عوامل زیر به ترتیب اهمیت برای تعیین کلاس برگزیده بررسی می‌شوند:
.br
\- کلاسی با سطح افزونگی (RL) بالاتر انتخاب می‌شود (بیشترین مقدار سطح افزونگی KEEP و ARCHIVE در نظر گرفته می‌شود)،
.br
\- کلاسی که در وضعیت ARCHIVE قالب EC دارد نسبت به کلاسی بدون EC ترجیح داده می‌شود،
.br
\- کلاسی که از برچسب‌ها برای وضعیت KEEP یا ARCHIVE استفاده می‌کند نسبت به کلاس بدون برچسب ترجیح داده می‌شود،
.br
\- کلاسی که در وضعیت TRASH قالب EC دارد نسبت به کلاسی بدون EC ترجیح داده می‌شود،
.br
\- کلاسی که از برچسب‌ها برای وضعیت TRASH استفاده می‌کند نسبت به کلاس بدون برچسب ترجیح داده می‌شود،
.br
\- در صورت تساوی تمام شرایط بالا، کلاسی با شناسه کلاس (Class ID) بالاتر انتخاب می‌شود.

.SS "کلاس‌های ذخیره‌سازی از پیش تعریف‌شده (PREDEFINED STORAGE CLASSES)"
.PP
یک نمونه تازه نصب‌شده از MooseFS دارای کلاس‌های پیش‌تعریف‌شده زیر خواهد بود:
.PP
2CP \- فقط وضعیت KEEP تعریف شده است، نگهداری ۲ نسخه روی هر برچسبی (کلاس پیش‌فرض برای دایرکتوری ریشه /).
.PP
3CP \- فقط وضعیت KEEP تعریف شده است، نگهداری ۳ نسخه روی هر برچسبی.
.PP
EC4+1 \- در وضعیت KEEP نگهداری ۲ نسخه روی هر برچسب، در وضعیت ARCHIVE نگهداری چانک‌ها در قالب EC4+1 روی هر برچسب، تاخیر آرشیو ۱ روز است و با ctime فایل محاسبه می‌شود، فایل‌های کوچک‌تر از 512KiB به قالب EC تبدیل نمی‌شوند.
.PP
EC4+2 \- (فقط نسخه Pro) در وضعیت KEEP نگهداری ۳ نسخه، در وضعیت ARCHIVE نگهداری در قالب EC4+2، تاخیر ۱ روز با ctime، فایل‌های کوچک‌تر از 512KiB تبدیل نمی‌شوند.
.PP
EC8+1 \- در وضعیت KEEP نگهداری ۲ نسخه، در وضعیت ARCHIVE نگهداری در قالب EC8+1، تاخیر ۱ روز با ctime، فایل‌های کوچک‌تر از 512KiB تبدیل نمی‌شوند.
.PP
EC8+2 \- (فقط نسخه Pro) در وضعیت KEEP نگهداری ۳ نسخه، در وضعیت ARCHIVE نگهداری در قالب EC8+2، تاخیر ۱ روز با ctime، فایل‌های کوچک‌تر از 512KiB تبدیل نمی‌شوند.
.PP
این کلاس‌ها کاملاً قابل ویرایش و حذف هستند و می‌توانند با کلاس‌های انتخابی کاربر جایگزین شوند.

.SH "مثال‌ها (EXAMPLES)"
.PP
ایجاد یک کلاس ذخیره‌سازی جدید به نام "Class2Copies" با ۲ نسخه کپی؛ نسخه اول روی یکی از چانک‌سرورهای با برچسب "A" و نسخه دوم روی یکی از چانک‌سرورهای با برچسب "B":
.PP
.B mfscreatesclass \-K "A,B" Class2Copies
.PP
ایجاد یک کلاس ذخیره‌سازی جدید به نام "Class3Copies"؛ چانک‌های تازه ایجادشده (\-C) در هر جایی با ۲ نسخه (2*) نگهداری می‌شوند؛ اندکی پس از ایجاد در ۳ نسخه (\-K) نگهداری خواهند شد: نسخه اول روی چانک‌سرور با برچسب "A"، نسخه دوم روی چانک‌سرور با برچسب "B" و نسخه سوم روی هر چانک‌سروری:
.PP
.B mfscreatesclass \-C '2*' \-K 'A,B,*' Class3Copies
.PP
ایجاد یک کلاس ذخیره‌سازی جدید به نام "ClassEC4_1"؛ چانک‌ها به مدت ۲۴ ساعت پس از ایجاد فایل در هر جایی در ۲ نسخه (2*) ایجاد و نگهداری (\-K) می‌شوند؛ سپس در قالب EC4+1 روی هر چانک‌سروری آرشیو (\-A) می‌شوند:
.PP
.B mfscreatesclass \-K '2*' \-A '@4+1' ClassEC4_1
.PP
تغییر کلاس ذخیره‌سازی "ClassEC4_1" برای آرشیو کردن چانک‌ها پس از ۴۸ ساعت از زمان تغییر فایل (mtime) نه زمان ایجاد آن:
.PP
.B mfsmodifysclass \-d 2d \-o m ClassEC4_1
.PP
تغییر کلاس ذخیره‌سازی "Class3Copies" برای نگهداری چانک‌ها روی سایر چانک‌سرورها (حالت LOOSE) در صورتی که سرورهای با برچسب "A" و "B" بیش از حد مشغول (overloaded) باشند:
.PP
.B mfsmodifysclass \-m l Class3Copies
.SH "گزارش باگ‌ها (REPORTING BUGS)"
اشکالات را به نشانی <bugs@moosefs.com> گزارش دهید.
.SH "حق نشر (COPYRIGHT)"
حق نشر (C) 2026 Jakub Kruszona-Zawadzki, Saglabs SA
.PP
این برنامه یک نرم‌افزار آزاد است؛ شما می‌توانید آن را تحت شرایط پروانه عمومی همگانی گنو (GNU GPL) نسخه ۲ بازتوزیع کرده یا تغییر دهید.
.SH "همچنین ببینید (SEE ALSO)"
.BR mfsmount (8),
.BR mfstools (1),
.BR mfssclass (1),
.BR mfsarchive (1),
.BR mfsscadmin (1)