ZFS

سیستم فایل

ZFS (قبلاً Zettabyte File System ) یک سیستم فایل با قابلیت مدیریت حجم است . این به عنوان بخشی از سیستم عامل Sun Microsystems Solaris در سال 2001 آغاز شد. بخش های بزرگی از Solaris، از جمله ZFS، تحت یک مجوز منبع باز به عنوان OpenSolaris برای حدود 5 سال از سال 2005 منتشر شد، قبل از اینکه تحت مجوز منبع بسته قرار گیرد زمانی که شرکت Oracle Sun را خریداری کرد. در سال 2009-2010. در طی سال‌های 2005 تا 2010، نسخه منبع باز ZFS به Linux ، Mac OS X (ادامه به عنوان MacZFS ) و FreeBSD منتقل شد . در سال 2010، پروژه illumos یک نسخه جدید از OpenSolaris، از جمله ZFS را برای ادامه توسعه خود به عنوان یک پروژه منبع باز ایجاد کرد . در سال 2013، OpenZFS برای هماهنگی توسعه ZFS منبع باز تاسیس شد. ^{[3] [4] [5]} OpenZFS کد اصلی ZFS را حفظ و مدیریت می‌کند، در حالی که سازمان‌هایی که از ZFS استفاده می‌کنند، کد خاص و فرآیندهای اعتبارسنجی مورد نیاز برای ZFS را برای ادغام در سیستم‌های خود حفظ می‌کنند. OpenZFS به طور گسترده در سیستم های شبه یونیکس استفاده می شود . ^{[6] [7] [8]}

نمای کلی

مدیریت داده‌های ذخیره‌شده عموماً شامل دو جنبه است: مدیریت حجم فیزیکی یک یا چند دستگاه ذخیره‌سازی بلوک (مانند دیسک‌های سخت و کارت‌های SD )، از جمله سازمان‌دهی آنها در دستگاه‌های بلوک منطقی به عنوان VDEV (دستگاه مجازی ZFS) ^[9] همانطور که مشاهده می‌شود. توسط سیستم عامل (اغلب شامل یک مدیر حجم ، کنترلر RAID ، مدیر آرایه یا درایور دستگاه مناسب ) و مدیریت داده ها و فایل هایی که در این دستگاه های بلوک منطقی (یک سیستم فایل یا سایر ذخیره سازی داده ها) ذخیره می شوند.

مثال: یک آرایه RAID از 2 هارد دیسک و یک دیسک کش SSD توسط سیستم RST اینتل کنترل می‌شود ، بخشی از چیپست و سیستم‌افزاری که در یک کامپیوتر رومیزی تعبیه شده است. کاربر ویندوز این را به عنوان یک جلد می بیند که حاوی یک درایو با فرمت NTFS از داده های خود است و NTFS لزوماً از دستکاری هایی که ممکن است مورد نیاز باشد (مانند خواندن از/نوشتن در درایو حافظه پنهان یا بازسازی آرایه RAID در صورت نیاز) آگاه نیست. یک دیسک از کار می افتد). مدیریت تک تک دستگاه ها و ارائه آنها به عنوان یک دستگاه مجزا از مدیریت فایل های نگهداری شده در آن دستگاه ظاهری است.

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

ZFS همچنین دارای مکانیزمی برای داده‌ها و عکس‌های فوری و تکرار در سطح استخر است ، از جمله شبیه‌سازی عکس فوری ، که توسط مستندات FreeBSD به عنوان یکی از «قوی‌ترین ویژگی‌ها» با عملکردی توصیف شده است که «حتی سایر سیستم‌های فایل با عملکرد عکس فوری فاقد آن هستند». ^[10] تعداد بسیار زیادی از عکس‌های فوری را می‌توان بدون کاهش عملکرد گرفت، که اجازه می‌دهد از عکس‌های فوری قبل از عملیات مخاطره‌آمیز سیستم و تغییرات نرم‌افزاری استفاده شود، یا از کل سیستم فایل تولیدی ("زنده") به طور کامل چندین بار در ساعت عکس‌برداری شود. برای کاهش از دست دادن داده ها به دلیل خطای کاربر یا فعالیت مخرب. عکس‌های فوری را می‌توان به صورت زنده بازگردانی کرد یا وضعیت‌های قبلی سیستم فایل را حتی در سیستم‌های فایل بسیار بزرگ مشاهده کرد، که منجر به صرفه‌جویی در مقایسه با فرآیندهای پشتیبان‌گیری و بازیابی رسمی می‌شود. ^[10] عکس های فوری را نیز می توان برای تشکیل فایل سیستم های مستقل جدید شبیه سازی کرد. ZFS همچنین توانایی گرفتن یک عکس فوری در سطح استخر (معروف به "نقطه بازرسی") را دارد که امکان بازگشت عملیاتی را که ممکن است کل ساختار استخر را تحت تاثیر قرار دهد یا کل مجموعه داده‌ها را اضافه یا حذف کند را دارد.

تاریخچه

2004-2010: توسعه در Sun Microsystems

در سال 1987، AT&T Corporation و Sun اعلام کردند که در پروژه ای برای ادغام محبوب ترین انواع یونیکس در بازار در آن زمان: Berkeley Software Distribution ، UNIX System V و Xenix همکاری می کنند . این نسخه Unix System V Release 4 (SVR4) شد. ^[11] این پروژه با نام Solaris منتشر شد ، که جانشین SunOS 4 شد (اگرچه نسخه‌های SunOS 4.1. x micro به صورت ماسبق به نام Solaris 1 نامگذاری شدند ). ^[12]

ZFS توسط تیمی در Sun به رهبری جف بونویک ، بیل مور، ^[13] و متیو آرنز طراحی و اجرا شد. در 14 سپتامبر 2004 اعلام شد، ^[14] اما توسعه در سال 2001 آغاز شد. ^[15] کد منبع برای ZFS در 31 اکتبر 2005 در صندوق اصلی توسعه Solaris ادغام شد ^[16] و به عنوان بخشی از ساخت برای توسعه دهندگان منتشر شد. 27 OpenSolaris در 16 نوامبر 2005. در ژوئن 2006، Sun اعلام کرد که ZFS در به روز رسانی اصلی 6/06 Solaris 10 گنجانده شده است . ^[17]

Solaris در ابتدا به عنوان نرم افزار اختصاصی توسعه داده شد ، اما Sun Microsystems یکی از طرفداران تجاری اولیه نرم افزار منبع باز بود و در ژوئن 2005 اکثر کدهای Solaris را تحت مجوز CDDL منتشر کرد و پروژه منبع باز OpenSolaris را تأسیس کرد . ^[18] در Solaris 10 6/06 ("U2")، Sun سیستم فایل ZFS را اضافه کرد و ZFS را به طور مکرر با ویژگی های جدید در طول 5 سال آینده به روز کرد. ZFS تحت این مجوز منبع باز به Linux ، Mac OS X (ادامه به عنوان MacZFS ) و FreeBSD منتقل شد .

نام در یک نقطه به معنای "Zettabyte File System" بود، ^[19] اما در سال 2006، نام دیگر به عنوان مخفف در نظر گرفته نمی شد. ^[20] یک سیستم فایل ZFS می تواند تا 256 کوادریلیون زتابایت (ZB) را ذخیره کند.

در سپتامبر 2007، NetApp از Sun شکایت کرد و ادعا کرد که ZFS برخی از پتنت های NetApp را در Write Anywhere File Layout نقض کرده است . Sun در اکتبر همان سال با ادعای خلاف این شکایت کرد. این دعاوی در سال 2010 با یک توافق نامعلوم پایان یافت. ^[21]

2010-اکنون: توسعه در اوراکل، OpenZFS

نسخه‌های پورت‌شده ZFS در سال 2005 ظاهر شدند. پس از خرید Sun توسط Oracle در سال 2010، نسخه Oracle از ZFS به منبع بسته تبدیل شد و توسعه نسخه‌های منبع باز به‌طور مستقل و با هماهنگی OpenZFS از سال 2013 ادامه یافت.

ویژگی ها

خلاصه

نمونه هایی از ویژگی های خاص ZFS عبارتند از:

• طراحی شده برای ذخیره‌سازی طولانی‌مدت داده‌ها و اندازه‌های ذخیره‌گاه داده با مقیاس نامحدود با از دست دادن داده‌های صفر و قابلیت پیکربندی بالا.
• جمع‌بندی سلسله مراتبی همه داده‌ها و ابرداده‌ها ، حصول اطمینان از اینکه می‌توان کل سیستم ذخیره‌سازی را در هنگام استفاده تأیید کرد، و تأیید کرد که به درستی ذخیره می‌شود، یا در صورت خرابی اصلاح می‌شود. جمع‌های چک با بلوک مادر بلوک ذخیره می‌شوند ، نه با خود بلوک. این در تضاد با بسیاری از سیستم‌های فایل است که در آن جمع‌های چک (در صورت نگهداری) با داده‌ها ذخیره می‌شوند، به طوری که اگر داده‌ها از بین بروند یا خراب شوند، جمع‌بندی چک نیز احتمالاً از بین می‌رود یا نادرست است.
• می‌تواند تعداد مشخصی از کپی‌های داده یا ابرداده یا انواع داده‌های انتخابی را ذخیره کند تا توانایی بازیابی از خرابی داده‌ها در فایل‌ها و ساختارهای مهم را بهبود بخشد.
• بازگرداندن خودکار تغییرات اخیر در سیستم فایل و داده ها، در برخی شرایط، در صورت بروز خطا یا ناهماهنگی.
• خودترمیمی خودکار و (معمولاً) بی‌صدا ناهماهنگی‌های داده‌ها و شکست نوشتن در هنگام شناسایی، برای همه خطاهایی که داده‌ها قابلیت بازسازی دارند. داده‌ها را می‌توان با استفاده از تمام موارد زیر بازسازی کرد: جمع‌آوری‌های بازرسی و تصحیح خطا که در بلوک اصلی هر بلوک ذخیره می‌شوند. چندین نسخه از داده ها (از جمله چک جمع ها) که روی دیسک نگهداری می شوند. نوشتن مقاصد ثبت‌شده در SLOG (ZIL) برای نوشته‌هایی که باید اتفاق می‌افتند اما رخ نداده‌اند (پس از قطع برق). داده های برابری از دیسک ها و حجم های RAID/RAID-Z. کپی از داده ها از دیسک های آینه ای و حجم.
• مدیریت بومی سطوح RAID استاندارد و طرح‌بندی‌های اضافی RAID ZFS ("RAID-Z"). RAID-Z داده‌ها را فقط روی دیسک‌های مورد نیاز برای کارآمدی سطح می‌کشد (بسیاری از سیستم‌های RAID به‌طور نامحسوس در همه دستگاه‌ها نوار می‌شوند)، و جمع‌بندی چک اجازه می‌دهد تا بازسازی داده‌های ناسازگار یا خراب به آن بلوک‌های دارای نقص به حداقل برسد.
• مدیریت داخلی دستگاه‌های ذخیره‌سازی و ذخیره‌سازی لایه‌ای، که معمولاً یک کار مرتبط با حجم است. از آنجایی که ZFS سیستم فایل را نیز می‌شناسد، می‌تواند از دانش مربوط به فایل برای اطلاع‌رسانی، ادغام و بهینه‌سازی مدیریت ذخیره‌سازی لایه‌ای خود استفاده کند که دستگاه جداگانه نمی‌تواند.
• مدیریت بومی عکس‌های فوری و پشتیبان‌گیری/ تکثیر که می‌تواند با یکپارچه‌سازی حجم و مدیریت فایل کارآمد شود. ابزارهای مربوطه در سطح پایینی ارائه می شوند و برای استفاده به اسکریپت ها و نرم افزارهای خارجی نیاز دارند.
• فشرده‌سازی و کپی‌سازی داده‌های بومی ، اگرچه دومی تا حد زیادی در RAM مدیریت می‌شود و نیاز به حافظه دارد.
• بازسازی کارآمد آرایه‌های RAID - یک کنترل‌کننده RAID اغلب مجبور است یک دیسک کامل را بازسازی کند، اما ZFS می‌تواند دانش دیسک و فایل را ترکیب کند تا هرگونه بازسازی را به داده‌هایی محدود کند که در واقع گم شده یا خراب شده‌اند، و به میزان زیادی سرعت بازسازی را افزایش می‌دهد.
• تحت تأثیر تغییرات سخت افزاری RAID که بر بسیاری از سیستم های دیگر تأثیر می گذارد. در بسیاری از سیستم‌ها، اگر سخت‌افزار RAID مستقل مانند کارت RAID از کار بیفتد، یا داده‌ها به سیستم RAID دیگری منتقل شوند، سیستم فایل فاقد اطلاعاتی است که روی سخت‌افزار اصلی RAID وجود دارد، که برای مدیریت داده‌ها در RAID لازم است. آرایه این می تواند منجر به از دست رفتن کل داده شود، مگر اینکه بتوان سخت افزار تقریباً یکسانی را به دست آورد و به عنوان "سنگ پله" استفاده کرد. از آنجایی که ZFS خودش RAID را مدیریت می کند، یک استخر ZFS می تواند به سخت افزار دیگر منتقل شود، یا سیستم عامل را می توان دوباره نصب کرد، و ساختارها و داده های RAID-Z شناسایی شده و بلافاصله توسط ZFS دوباره در دسترس خواهند بود.
• توانایی شناسایی داده‌هایی که در حافظه پنهان پیدا می‌شدند اما اخیراً حذف شده‌اند. این امر به ZFS اجازه می‌دهد تا تصمیمات ذخیره‌سازی خود را با توجه به استفاده‌های بعدی ارزیابی کند و سطوح ضربه‌های کش بسیار بالا را تسهیل می‌کند (نرخ بازدید حافظه پنهان ZFS معمولاً بیش از ۸۰٪ است).
• استراتژی‌های ذخیره‌سازی جایگزین می‌توانند برای داده‌هایی استفاده شوند که در غیر این صورت باعث تأخیر در پردازش داده‌ها می‌شوند. به عنوان مثال، نوشته‌های همزمان که می‌توانند سرعت سیستم ذخیره‌سازی را کاهش دهند، می‌توانند با نوشتن در یک دستگاه ذخیره‌سازی سریع جداگانه، معروف به SLOG (که گاهی اوقات به نام ZIL – ZFS Intent Log نامیده می‌شود) به نوشته‌های ناهمزمان تبدیل شوند.
• بسیار قابل تنظیم - بسیاری از پارامترهای داخلی را می توان برای عملکرد بهینه پیکربندی کرد.
• می تواند برای خوشه های در دسترس بالا و محاسبات استفاده شود ، اگرچه به طور کامل برای این استفاده طراحی نشده است.

یکپارچگی داده ها

یکی از ویژگی‌های اصلی که ZFS را از سایر سیستم‌های فایل متمایز می‌کند این است که با تمرکز بر یکپارچگی داده‌ها با محافظت از داده‌های کاربر روی دیسک در برابر خرابی داده‌های بی‌صدا ناشی از تخریب داده‌ها ، نوسانات برق ( بالاهای ولتاژ )، اشکالات در سیستم عامل دیسک ، فانتوم طراحی شده است. می نویسد (نوشتن قبلی به دیسک نمی رسد)، خواندن/نوشتن اشتباه هدایت می شود (دیسک به بلوک اشتباه دسترسی پیدا می کند)، خطاهای برابری DMA بین آرایه و حافظه سرور یا از درایور (از آنجایی که جمع کنترلی داده های داخل آرایه را تایید می کند)، خطاهای درایور (داده ها در بافر اشتباه داخل هسته جمع می شوند)، بازنویسی های تصادفی (مانند تعویض به یک سیستم فایل زنده) و غیره.

مطالعه‌ای در سال 1999 نشان داد که نه هیچ یک از سیستم‌های فایل اصلی و گسترده در آن زمان (مانند UFS ، Ext ، ^[22] XFS ، JFS ، یا NTFS )، و نه RAID سخت‌افزاری (که مشکلاتی با یکپارچگی داده‌ها دارد ) محافظت کافی در برابر داده‌ها ارائه نکرده است. مشکلات فساد ^{[23] [24] [25] [26]} تحقیقات اولیه نشان می دهد که ZFS از داده ها بهتر از تلاش های قبلی محافظت می کند. ^{[27] [28]} همچنین سریعتر از UFS ^{[29] [30]} است و می توان آن را جایگزین آن دانست.

در ZFS، یکپارچگی داده ها با استفاده از یک چک جمع مبتنی بر فلچر یا یک هش SHA-256 در سراسر درخت سیستم فایل به دست می آید. ^[31] هر بلوک داده جمع‌بندی می‌شود و مقدار چک جمع‌آوری سپس در نشانگر آن بلوک ذخیره می‌شود - نه در خود بلوک واقعی. سپس، نشانگر بلوک جمع‌بندی می‌شود و مقدار در نشانگر آن ذخیره می‌شود . این جمع‌بندی چک تا آخر سلسله مراتب داده‌های سیستم فایل تا گره ریشه ادامه می‌یابد، که جمع‌بندی نیز چک می‌شود، بنابراین یک درخت Merkle ایجاد می‌کند . ^[31] خرابی داده‌های حین پرواز یا خواندن/نوشتن فانتوم (داده‌های نوشته‌شده/خوانده شده به درستی جمع‌بندی‌های چک را می‌خوانند، اما در واقع اشتباه هستند) توسط اکثر فایل‌سیستم‌ها غیرقابل شناسایی هستند، زیرا آنها چک‌سوم را با داده‌ها ذخیره می‌کنند. ZFS جمع چک هر بلوک را در نشانگر بلوک والد خود ذخیره می‌کند تا کل استخر خود تأیید شود. ^[31]

هنگامی که به یک بلوک دسترسی پیدا می شود، صرف نظر از اینکه آن داده یا فراداده باشد، جمع چک آن محاسبه می شود و با مقدار جمع کنترل ذخیره شده آن چیزی که «باید» باشد مقایسه می شود. اگر جمع‌های چک مطابقت داشته باشند، داده‌ها از پشته برنامه‌نویسی به فرآیندی که آن را درخواست کرده است منتقل می‌شود. اگر مقادیر مطابقت نداشته باشند، در صورتی که استخر ذخیره‌سازی افزونگی داده‌ها را فراهم کند ، با فرض اینکه کپی داده‌ها آسیبی ندیده و دارای جمع‌های بررسی منطبق باشد، ZFS می‌تواند داده‌ها را بهبود بخشد. ^[32] به صورت اختیاری می‌توان افزونگی اضافی درون استخر را با مشخص کردن کپی=2 (یا کپی=3 ) فراهم کرد، به این معنی که داده‌ها دو بار (یا سه بار) روی دیسک ذخیره می‌شوند و عملاً نصف می‌شوند (یا برای کپی‌ها ). = 3 ، کاهش به یک سوم) ظرفیت ذخیره سازی دیسک. ^[33] به‌علاوه، برخی از انواع داده‌هایی که توسط ZFS برای مدیریت استخر مورد استفاده قرار می‌گیرند، به‌طور پیش‌فرض برای ایمنی حتی با تنظیم پیش‌فرض کپی=1، چندین بار ذخیره می‌شوند.

اگر نسخه‌های دیگری از داده‌های آسیب‌دیده وجود داشته باشد یا بتوان آن‌ها را از جمع‌های چک و داده‌های برابری بازسازی کرد ، ZFS از یک کپی از داده‌ها استفاده می‌کند (یا آن‌ها را از طریق مکانیزم بازیابی RAID دوباره ایجاد می‌کند) و چک‌سوم را مجدداً محاسبه می‌کند – که در حالت ایده‌آل منجر به بازتولید مقدار مورد انتظار اولیه می‌شود. ارزش اگر داده‌ها از این بررسی یکپارچگی عبور کنند، سیستم می‌تواند تمام نسخه‌های معیوب را با داده‌های خوب به‌روزرسانی کند و افزونگی بازیابی می‌شود.

اگر هیچ نسخه‌ای از داده‌های آسیب‌دیده وجود نداشته باشد، ZFS استخر را در وضعیت معیوب قرار می‌دهد، ^[34] از استفاده آینده آن جلوگیری می‌کند و هیچ راه مستندی برای بازیابی محتویات استخر ارائه نمی‌دهد.

سازگاری داده‌های نگهداری شده در حافظه، مانند داده‌های کش شده در ARC، به‌طور پیش‌فرض بررسی نمی‌شود، زیرا انتظار می‌رود ZFS روی سخت‌افزار با کیفیت سازمانی با RAM اصلاح‌کننده خطا اجرا شود . با این حال، قابلیت بررسی داده های درون حافظه وجود دارد و می توان آن را با استفاده از "پرچم های اشکال زدایی" فعال کرد. ^[35]

RAID ("RAID-Z")

برای اینکه ZFS بتواند یکپارچگی داده ها را تضمین کند، به چندین نسخه از داده ها نیاز دارد که معمولاً در چندین دیسک پخش می شوند. این معمولاً با استفاده از یک کنترلر RAID یا به اصطلاح RAID "نرم" (ساخته شده در یک سیستم فایل ) به دست می آید.

اجتناب از کنترلرهای RAID سخت افزاری

در حالی که ZFS می‌تواند با دستگاه‌های RAID سخت‌افزاری کار کند ، اگر دسترسی خام به همه دستگاه‌های ذخیره‌سازی داشته باشد، معمولاً کارآمدتر و با محافظت از داده‌های بیشتری کار می‌کند. ZFS برای یک دید صادقانه برای تعیین لحظه ای که داده ها به صورت ایمن نوشته شده اند، به دیسک متکی است و الگوریتم های متعددی دارد که برای بهینه سازی استفاده از کش ، شستشوی کش و مدیریت دیسک طراحی شده است.

دیسک‌هایی که با استفاده از سخت‌افزار، سفت‌افزار، دیگر RAID «نرم» یا هر کنترل‌کننده دیگری که مسیر ورودی/خروجی ZFS به دیسک را تغییر می‌دهد، به سیستم متصل شده‌اند، بر عملکرد ZFS و یکپارچگی داده‌ها تأثیر می‌گذارند. اگر یک دستگاه شخص ثالث ذخیره سازی را انجام دهد یا درایوها را به عنوان یک سیستم واحد به ZFS ارائه کند، بدون اینکه ZFS به نمای سطح پایینی متکی باشد، احتمال بسیار بیشتری وجود دارد که سیستم عملکرد بهینه کمتری داشته باشد و احتمال اینکه ZFS کمتر از خرابی جلوگیری کند، وجود دارد. بازیابی از خرابی ها با کندی بیشتر، یا از دست دادن داده ها به دلیل شکست نوشتن. به عنوان مثال، اگر از کارت RAID سخت افزاری استفاده شود، ZFS ممکن است نتواند وضعیت دیسک ها را تعیین کند، تعیین کند که آیا آرایه RAID تخریب شده یا در حال بازسازی است، تمام خرابی داده ها را شناسایی کند، داده ها را به طور بهینه در بین دیسک ها قرار دهد، تعمیرات انتخابی انجام دهد، کنترل کند. چگونه تعمیرات با استفاده مداوم متعادل می شوند یا تعمیراتی را انجام می دهند که ZFS معمولاً می تواند انجام دهد. کارت RAID سخت افزاری با الگوریتم های ZFS تداخل خواهد داشت. کنترل‌کننده‌های RAID معمولاً داده‌های وابسته به کنترلر را به درایوها اضافه می‌کنند که مانع از دسترسی نرم‌افزار RAID به داده‌های کاربر می‌شود. در صورت خرابی کنترلر RAID سخت افزاری، ممکن است بتوان داده ها را با کنترلر سازگار دیگری خواند، اما همیشه این امکان وجود ندارد و ممکن است جایگزینی در دسترس نباشد. کنترل‌کننده‌های RAID سخت‌افزاری جایگزین ممکن است داده‌های سفارشی سازنده اصلی مورد نیاز برای مدیریت و بازیابی یک آرایه را درک نکنند.

برخلاف اکثر سیستم‌های دیگر که کارت‌های RAID یا سخت‌افزارهای مشابه می‌توانند منابع و پردازش‌ها را برای افزایش عملکرد و قابلیت اطمینان بارگیری کنند، با ZFS اکیداً توصیه می‌شود که از این روش‌ها استفاده نشوند زیرا معمولاً عملکرد و قابلیت اطمینان سیستم را کاهش می‌دهند .

اگر دیسک‌ها باید از طریق یک RAID یا کنترل‌کننده دیگر متصل شوند، توصیه می‌شود با استفاده از یک HBA ساده (آداپتور میزبان) ، یک کارت ساده فن‌آوت ، یا پیکربندی کارت در حالت JBOD (یعنی چرخش) میزان پردازش انجام شده در کنترل‌کننده را به حداقل برسانید. غیرفعال کردن RAID و توابع حافظه پنهان)، اجازه می دهد دستگاه ها با حداقل تغییرات در مسیر ورودی/خروجی ZFS به دیسک متصل شوند. یک کارت RAID در حالت JBOD در صورتی که حافظه پنهان داشته باشد همچنان ممکن است تداخل داشته باشد یا بسته به طراحی آن، ممکن است درایوهایی را که به موقع پاسخ نمی‌دهند جدا کند (همانطور که در بسیاری از هارد دیسک‌های مصرف‌کننده کارآمد دیده شده است) و به همین ترتیب. ، ممکن است برای جلوگیری از افت درایو به درایوهای دارای بازیابی خطای محدود (TLER)/CCTL/ERC نیاز داشته باشد، بنابراین همه کارت‌ها حتی با غیرفعال شدن عملکردهای RAID مناسب نیستند. ^[36]

رویکرد ZFS: RAID-Z و mirroring

به جای RAID سخت افزاری، ZFS از RAID "نرم" استفاده می کند و RAID-Z ( بر اساس برابری مانند RAID 5 و موارد مشابه) و انعکاس دیسک (مشابه RAID 1 ) را ارائه می دهد. طرح ها بسیار انعطاف پذیر هستند.

RAID-Z یک طرح توزیع داده/تعادل مانند RAID-5 است ، اما از عرض نوار پویا استفاده می‌کند: هر بلوک بدون در نظر گرفتن اندازه بلوک، نوار RAID خودش است، که در نتیجه هر نوشتن RAID-Z یک نوشتن نوار کامل است. این، هنگامی که با معنای تراکنشی کپی روی نوشتار ZFS ترکیب می‌شود، خطای سوراخ نوشتن را حذف می‌کند . RAID-Z همچنین سریعتر از RAID 5 سنتی است، زیرا نیازی به انجام دنباله معمول خواندن، اصلاح و نوشتن ندارد . ^[37]

از آنجایی که همه نوارها اندازه‌های متفاوتی دارند، بازسازی RAID-Z باید فراداده‌های سیستم فایل را برای تعیین هندسه واقعی RAID-Z طی کند. اگر سیستم فایل و آرایه RAID محصولات جداگانه باشند، این امر غیرممکن خواهد بود، در حالی که زمانی که یک نمای یکپارچه از ساختار منطقی و فیزیکی داده ها وجود داشته باشد، امکان پذیر می شود. مرور ابرداده به این معنی است که ZFS می‌تواند هر بلوک را با جمع‌بندی 256 بیتی خود اعتبارسنجی کند، در حالی که محصولات RAID سنتی معمولاً نمی‌توانند این کار را انجام دهند. ^[37]

علاوه بر مدیریت خرابی‌های کل دیسک، RAID-Z همچنین می‌تواند خرابی داده‌های بی‌صدا را شناسایی و تصحیح کند ، و «داده‌های خود درمانی» را ارائه می‌دهد: هنگام خواندن یک بلوک RAID-Z، ZFS آن را با جمع کنترلی خود مقایسه می‌کند، و اگر دیسک‌های داده این کار را انجام دادند. پاسخ صحیح را بر نمی گرداند، ZFS برابری را می خواند و سپس متوجه می شود که کدام دیسک داده های بد را برگردانده است. سپس داده های آسیب دیده را تعمیر می کند و داده های خوبی را به درخواست کننده برمی گرداند. ^[37]

RAID-Z و mirroring به سخت افزار خاصی نیاز ندارند: برای قابلیت اطمینان به NVRAM نیاز ندارند و برای عملکرد خوب یا محافظت از داده ها به بافر نوشتن نیاز ندارند. با RAID-Z، ZFS با استفاده از دیسک های ارزان قیمت، ذخیره سازی سریع و قابل اعتمادی را فراهم می کند. ^{[ ارتقاء؟ ] [37]}

پنج حالت مختلف RAID-Z وجود دارد: striping (مشابه RAID 0، بدون افزونگی)، RAID-Z1 (مشابه RAID 5، اجازه می دهد تا یک دیسک خراب شود)، RAID-Z2 (شبیه به RAID 6، به دو دیسک اجازه می دهد تا Fail)، RAID-Z3 (پیکربندی RAID 7 ^[a] ، اجازه می‌دهد سه دیسک از کار بیفتد)، و mirroring (مشابه RAID 1، به همه دیسک‌ها به جز یک امکان خرابی می‌دهد). ^[39]

نیاز به RAID-Z3 در اوایل دهه 2000 به وجود آمد زیرا درایوهای با ظرفیت چند ترابایتی رایج تر شدند. این افزایش ظرفیت - بدون افزایش سرعت خروجی متناظر - به این معنی بود که بازسازی یک آرایه به دلیل یک درایو ناموفق می‌تواند «به راحتی هفته‌ها یا ماه‌ها» تکمیل شود. ^[38] در طول این مدت، دیسک‌های قدیمی‌تر در آرایه تحت فشار بار کاری اضافی قرار می‌گیرند که می‌تواند منجر به خراب شدن داده‌ها یا خرابی درایو شود. با افزایش برابری، RAID-Z3 شانس از دست دادن داده ها را با افزایش سادگی کاهش می دهد. ^[40]

سیلورینگ و اسکراب (همگام سازی آرایه و بررسی یکپارچگی)

ZFS هیچ ابزاری معادل fsck (ابزار استاندارد چک کردن و تعمیر داده های یونیکس و لینوکس برای سیستم های فایل) ندارد. ^{[41] در عوض، ZFS دارای یک عملکرد} اسکراب داخلی است که به طور منظم تمام داده ها را بررسی می کند و فساد خاموش و سایر مشکلات را تعمیر می کند. برخی از تفاوت ها عبارتند از:

• fsck باید روی یک فایل سیستم آفلاین اجرا شود، به این معنی که فایل سیستم باید unmount شود و در حین تعمیر قابل استفاده نیست، در حالی که scrub برای استفاده در فایل سیستم نصب شده و زنده طراحی شده است و نیازی به فایل سیستم فایل ZFS برای آفلاین شدن ندارد.
• fsck معمولاً فقط ابرداده ها (مانند گزارش مجله) را بررسی می کند اما هرگز خود داده ها را بررسی نمی کند. این بدان معناست که پس از یک fsck، ممکن است داده ها همچنان با داده های اصلی ذخیره شده مطابقت نداشته باشند.
• fsck همیشه نمی‌تواند داده‌ها را زمانی که چک‌سام‌ها با داده‌ها ذخیره می‌شوند اعتبارسنجی و تعمیر کند (اغلب در بسیاری از سیستم‌های فایل چنین است)، زیرا جمع‌های چک ممکن است خراب یا ناخوانا باشند. ZFS همیشه چک‌سام‌ها را جدا از داده‌هایی که تأیید می‌کند ذخیره می‌کند و قابلیت اطمینان و توانایی اسکراب برای تعمیر حجم را بهبود می‌بخشد. ZFS همچنین چندین نسخه از داده ها را ذخیره می کند - به ویژه ابرداده ها ممکن است بیش از 4 یا 6 نسخه داشته باشند (چند کپی در هر دیسک و چندین آینه دیسک در هر جلد) که تا حد زیادی توانایی اسکراب برای شناسایی و ترمیم آسیب های گسترده به حجم را بهبود می بخشد. در مقایسه با fsck.
• اسکراب همه چیز را بررسی می کند، از جمله ابرداده و داده ها. این اثر را می‌توان با مقایسه fsck با زمان‌های اسکراب مشاهده کرد - گاهی اوقات fsck در یک RAID بزرگ در چند دقیقه کامل می‌شود، به این معنی که فقط ابرداده بررسی می‌شود. عبور از تمام ابرداده ها و داده ها در یک RAID بزرگ ساعت ها طول می کشد، این دقیقا همان کاری است که scrub انجام می دهد.
• در حالی که fsck با استفاده از داده‌های سیستم فایل موجود، خطاها را شناسایی کرده و سعی در رفع آنها می‌کند، اسکراب برای بازیابی مشکلات به افزونگی متکی است. در حالی که fsck پیشنهاد می‌کند سیستم فایل را با از دست دادن جزئی داده تعمیر کند، در صورت عدم وجود افزونگی، اسکراب آن را در حالت خطا قرار می‌دهد. ^[34]

توصیه رسمی Sun/Oracle این است که دیسک‌های سطح سازمانی را یک‌بار در ماه تمیز کنید و دیسک‌های کالای ارزان‌تر را هفته‌ای یک‌بار تمیز کنید. ^{[42] [43]}

ظرفیت

ZFS یک سیستم فایل 128 بیتی است، ^{[44] [16]} بنابراین می تواند داده های 1.84 × 10 ¹⁹ برابر بیشتر از سیستم های 64 بیتی مانند Btrfs را آدرس دهی کند . حداکثر محدودیت های ZFS به گونه ای طراحی شده اند که هرگز در عمل با آنها مواجه نشوید. به عنوان مثال، پر کردن کامل یک zpool منفرد با 2 ¹²⁸ بیت داده، به  درایو دیسک سخت 3×10 ^{24 ترابایتی نیاز دارد. [45]}

برخی از محدودیت های نظری در ZFS عبارتند از:

• 16 اگزبی بایت (2 ⁶⁴ بایت): حداکثر اندازه یک فایل
• 2 ⁴⁸ : تعداد ورودی ها در هر دایرکتوری فردی ^[46]
• 16 exbibytes: حداکثر اندازه هر ویژگی
• 2 ⁵⁶ : تعداد ویژگی های یک فایل (در واقع به 2 ⁴⁸ برای تعداد فایل های یک فهرست محدود شده است)
• 256 کوادریلیون زبی بایت (2 ¹²⁸ بایت): حداکثر اندازه هر zpool
• 2 ⁶⁴ : تعداد دستگاه ها در هر zpool
• 2 ⁶⁴ : تعداد فایل سیستم ها در zpool
• 2 ⁶⁴ : تعداد zpool ها در یک سیستم

رمزگذاری

با Oracle Solaris، قابلیت رمزگذاری در ZFS ^[47] در خط لوله I/O تعبیه شده است. در طول نوشتن، یک بلوک ممکن است فشرده، رمزگذاری شود، جمع بندی شود و سپس کپی شود. خط‌مشی برای رمزگذاری در سطح مجموعه داده‌ها تنظیم می‌شود که مجموعه‌های داده (سیستم‌های فایل یا ZVOL) ایجاد می‌شوند. کلیدهای بسته بندی ارائه شده توسط کاربر/مدیر را می توان در هر زمان بدون آفلاین کردن سیستم فایل تغییر داد. رفتار پیش‌فرض این است که کلید بسته‌بندی توسط هر مجموعه داده فرزند به ارث می‌رسد. کلیدهای رمزگذاری داده ها به طور تصادفی در زمان ایجاد مجموعه داده تولید می شوند. فقط مجموعه داده های نسل (عکس های فوری و کلون ها) کلیدهای رمزگذاری داده ها را به اشتراک می گذارند. ^[48] ​​فرمانی برای تغییر به یک کلید رمزگذاری داده جدید برای کلون یا در هر زمان ارائه می‌شود - این داده‌های موجود را دوباره رمزگذاری نمی‌کند، در عوض از مکانیزم کلید اصلی رمزگذاری شده استفاده می‌کند.

از سال 2019، ^{[به روز رسانی]}ویژگی رمزگذاری نیز به طور کامل در OpenZFS 0.8.0 موجود برای توزیع‌های لینوکس دبیان و اوبونتو ادغام شده است. ^[49]

گزارش‌های حکایتی کاربر نهایی از خرابی هنگام استفاده از رمزگذاری بومی ZFS وجود دارد. علت دقیقی مشخص نشده است. ^{[50] [51]}

کارایی خواندن/نوشتن

ZFS به‌طور خودکار ذخیره‌سازی داده‌ها را در تمام vdev‌های یک Pool (و همه دستگاه‌های هر vdev) به‌گونه‌ای اختصاص می‌دهد که به طور کلی عملکرد استخر را به حداکثر می‌رساند. ZFS همچنین استراتژی نوشتن خود را برای در نظر گرفتن دیسک های جدید اضافه شده به یک استخر، زمانی که آنها اضافه می شوند، به روز می کند.

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

فضای آزاد در ZFS با استفاده از هم پراکنده می شود. ZFS مکانیزمی برای یکپارچه سازی فضای آزاد ندارد. زمانی که تکه تکه شدن فضای آزاد زیاد با استفاده بیش از حد از فضای دیسک همراه باشد، گزارش‌های کاربر نهایی حکایتی از کاهش عملکرد وجود دارد. ^{[52] [53]}

ویژگی های دیگر

دستگاه های ذخیره سازی، قطعات یدکی و سهمیه ها

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

ترکیب استخر ذخیره‌سازی به دستگاه‌های مشابه محدود نمی‌شود، بلکه می‌تواند شامل مجموعه‌های موقت و ناهمگن از دستگاه‌ها باشد، که ZFS به‌طور یکپارچه با هم ترکیب می‌کند و متعاقباً در صورت نیاز فضا را به مجموعه داده‌ها (نمونه‌های سیستم فایل یا ZVOL) اختصاص می‌دهد. انواع دستگاه های ذخیره سازی خودسرانه را می توان به استخرهای موجود اضافه کرد تا اندازه آنها افزایش یابد. ^[54]

ظرفیت ذخیره سازی همه vdev ها برای همه نمونه های سیستم فایل در zpool در دسترس است. یک سهمیه را می توان برای محدود کردن فضایی که یک نمونه سیستم فایل می تواند اشغال کند تنظیم کرد، و می توان یک رزرو تنظیم کرد تا تضمین کند که فضا برای یک نمونه سیستم فایل در دسترس خواهد بود.

مکانیسم های ذخیره سازی: ARC، L2ARC، گروه های تراکنش، ZIL، SLOG، VDEV ویژه

ZFS از لایه های مختلف کش دیسک برای سرعت بخشیدن به عملیات خواندن و نوشتن استفاده می کند. در حالت ایده آل، تمام داده ها باید در RAM ذخیره شوند، اما معمولاً بسیار گران است. بنابراین، داده ها به طور خودکار در یک سلسله مراتب برای بهینه سازی عملکرد در مقابل هزینه ذخیره می شوند. ^[55] اینها اغلب "استخرهای ذخیره سازی ترکیبی" نامیده می شوند. ^[56] داده‌هایی که اغلب در دسترس هستند در RAM ذخیره می‌شوند، و داده‌هایی که کمتر به آنها دسترسی پیدا می‌کند را می‌توان در رسانه‌های کندتر، مانند درایوهای حالت جامد (SSD) ذخیره کرد. داده‌هایی که اغلب به آنها دسترسی نمی‌یابد، کش نمی‌شوند و روی هارد دیسک‌های کند باقی می‌مانند. اگر داده های قدیمی به طور ناگهانی زیاد خوانده شوند، ZFS به طور خودکار آنها را به SSD یا RAM منتقل می کند.

مکانیزم‌های ذخیره‌سازی ZFS شامل یکی برای خواندن و نوشتن است، و در هر مورد، دو سطح کش می‌تواند وجود داشته باشد، یکی در حافظه رایانه (RAM) و دیگری در ذخیره‌سازی سریع (معمولاً درایوهای حالت جامد (SSD)). چهار کش

تعدادی کش دیگر، تقسیم کش و صف نیز در ZFS وجود دارد. به عنوان مثال، هر VDEV کش داده های خود را دارد و حافظه پنهان ARC بین داده های ذخیره شده توسط کاربر و ابرداده های مورد استفاده توسط ZFS با کنترل بر تعادل بین آنها تقسیم می شود.

کلاس ویژه VDEV

در OpenZFS 0.8 و نسخه‌های جدیدتر، می‌توان یک کلاس VDEV ویژه را پیکربندی کرد تا ترجیحاً ابرداده‌های سیستم فایل و به‌طور اختیاری جدول Deduplication داده‌ها (DDT) و بلوک‌های سیستم فایل کوچک ذخیره شود. ^[58] این اجازه می دهد، برای مثال، برای ایجاد یک VDEV ویژه در ذخیره سازی حالت جامد سریع برای ذخیره ابرداده، در حالی که داده های فایل معمولی در دیسک های در حال چرخش ذخیره می شود. این کار عملیات فشرده ابرداده مانند پیمایش سیستم فایل، اسکراب، و سیلور را بدون هزینه ذخیره کل فایل سیستم در ذخیره سازی حالت جامد، سرعت می بخشد.

مدل تراکنشی کپی بر روی نوشتن

ZFS از یک مدل شی تراکنشی کپی روی نوشتن استفاده می کند . همه نشانگرهای بلوک در سیستم فایل حاوی یک جمع کنترلی 256 بیتی یا هش 256 بیتی (در حال حاضر یک انتخاب بین Fletcher-2 ، Fletcher-4 ، یا SHA-256 ) ^[59] از بلوک هدف هستند، که زمانی که بلوک تأیید می شود، تأیید می شود. خواندن بلوک های حاوی داده های فعال هرگز در جای خود بازنویسی نمی شوند. در عوض، یک بلوک جدید تخصیص داده می‌شود، داده‌های اصلاح‌شده روی آن نوشته می‌شود، سپس هر بلوک ابرداده‌ای که به آن ارجاع می‌دهد به طور مشابه خوانده، تخصیص مجدد و نوشته می‌شود. برای کاهش هزینه‌های سربار این فرآیند، به‌روزرسانی‌های متعدد در گروه‌های تراکنش گروه‌بندی می‌شوند و حافظه پنهان نوشتن ZIL ( log intent ) زمانی استفاده می‌شود که معنای نوشتن همزمان مورد نیاز باشد. بلوک‌ها به‌صورت درختی چیده شده‌اند، و همچنین جمع‌های کنترلی آن‌ها (به طرح امضای مرکل مراجعه کنید ).

عکس های فوری و کلون

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

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

ارسال و دریافت عکس های فوری

سیستم های فایل ZFS را می توان به استخرهای دیگر منتقل کرد، همچنین در هاست های راه دور از طریق شبکه، زیرا دستور send نمایش جریانی از وضعیت سیستم فایل ایجاد می کند. این جریان می تواند محتویات کامل سیستم فایل را در یک عکس فوری مشخص توصیف کند یا می تواند یک دلتا بین عکس های فوری باشد. محاسبه جریان دلتا بسیار کارآمد است و اندازه آن به تعداد بلوک های تغییر یافته بین عکس های فوری بستگی دارد. این یک استراتژی کارآمد را فراهم می کند، به عنوان مثال، برای همگام سازی نسخه های پشتیبان خارج از سایت یا آینه های در دسترس بودن بالا از یک استخر.

راه راه پویا

خط‌بندی پویا در همه دستگاه‌ها برای به حداکثر رساندن توان به این معنی است که با اضافه شدن دستگاه‌های اضافی به zpool، عرض نوار به طور خودکار گسترش می‌یابد تا آنها را در بر بگیرد. بنابراین، همه دیسک‌های موجود در یک Pool استفاده می‌شوند که بار نوشتن را در آنها متعادل می‌کند. ^[60]

اندازه بلوک های متغیر

ZFS از بلوک‌هایی با اندازه متغیر استفاده می‌کند که اندازه پیش‌فرض آن ۱۲۸ کیلوبایت است. ویژگی‌های موجود به سرپرست اجازه می‌دهد حداکثر اندازه بلوک مورد استفاده را تنظیم کند، زیرا بارهای کاری خاص با بلوک‌های بزرگ به خوبی کار نمی‌کنند. اگر فشرده سازی داده ها فعال باشد، از اندازه بلوک های متغیر استفاده می شود. اگر بتوان یک بلوک را فشرده کرد تا در اندازه بلوک کوچک‌تر قرار بگیرد، اندازه کوچک‌تر روی دیسک استفاده می‌شود تا از فضای ذخیره‌سازی کمتر و بهبود توان IO استفاده شود (البته به قیمت افزایش استفاده از CPU برای عملیات فشرده‌سازی و رفع فشرده‌سازی). ^[61]

ایجاد سیستم فایل سبک

در ZFS، دستکاری سیستم فایل در یک مخزن ذخیره سازی آسان تر از دستکاری حجم در یک فایل سیستم سنتی است. زمان و تلاش مورد نیاز برای ایجاد یا گسترش یک فایل سیستم ZFS به زمان ساخت یک فهرست جدید نزدیک تر از دستکاری حجم در برخی سیستم های دیگر است. ^{[ نیازمند منبع ]}

پایان پذیری تطبیقی

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

این بر داده های ذخیره شده تأثیر نمی گذارد. همانطور که در سیستم‌های POSIX معمول است ، فایل‌ها به عنوان آرایه‌های ساده از بایت‌ها در برنامه‌ها به نظر می‌رسند، بنابراین برنامه‌هایی که داده‌ها را ایجاد می‌کنند و می‌خوانند، مسئول انجام این کار به روشی مستقل از endianness سیستم اصلی هستند.

کپی برداری

قابلیت‌های حذف مجدد داده‌ها در پایان اکتبر 2009 به مخزن منبع ZFS اضافه شد، ^[62] و بسته‌های توسعه OpenSolaris ZFS مربوطه از 3 دسامبر 2009 (بیلد 128) در دسترس هستند.

استفاده موثر از deduplication ممکن است به ظرفیت RAM بزرگ نیاز داشته باشد. توصیه ها بین 1 تا 5 گیگابایت رم برای هر ترابایت فضای ذخیره سازی است. ^{[63] [64] [65]} ارزیابی دقیق حافظه مورد نیاز برای حذف مجدد با مراجعه به تعداد بلوک‌های منحصر به فرد در استخر، و تعداد بایت‌های روی دیسک و RAM ("هسته") مورد نیاز برای ذخیره سازی انجام می‌شود. هر رکورد - این ارقام با دستورات داخلی مانند zpoolو گزارش می شوند zdb. حافظه فیزیکی ناکافی یا فقدان حافظه نهان ZFS می‌تواند منجر به از بین رفتن حافظه مجازی در هنگام استفاده از دوبله شود، که می‌تواند باعث کاهش شدید عملکرد یا کاهش کامل حافظه شود. ^{[ نیاز به ذکر منبع ]} از آنجایی که کپی‌برداری در زمان نوشتن اتفاق می‌افتد، همچنین بسیار به CPU فشرده است و همچنین می‌تواند به طور قابل توجهی سرعت سیستم را کاهش دهد.

سایر فروشندگان ذخیره سازی از نسخه های اصلاح شده ZFS برای دستیابی به نسبت فشرده سازی داده بسیار بالا استفاده می کنند . دو نمونه در سال 2012 GreenBytes ^[66] و Tegile بودند . ^[67] در ماه مه 2014، اوراکل GreenBytes را برای فناوری حذف و تکرار ZFS خریداری کرد. ^[68]

همانطور که در بالا توضیح داده شد، به دلیل نیاز به منابع سنگین (به ویژه RAM) و تأثیر بر عملکرد (مخصوصاً هنگام نوشتن)، معمولاً حذف مجدد توصیه نمی شود، به جز در شرایط خاصی که سیستم و داده ها به خوبی برای این تکنیک صرفه جویی در فضا مناسب هستند.

قابلیت های اضافی

• اولویت صریح I/O با زمان‌بندی مهلت. ^{[ نیازمند منبع ]}
• مرتب‌سازی و تجمیع ورودی/خروجی بهینه جهانی ادعا شده است. ^{[ نیازمند منبع ]}
• چند جریان پیش واکشی مستقل با تشخیص طول و گام خودکار. ^{[ نیازمند منبع ]}
• عملیات دایرکتوری موازی با زمان ثابت. ^{[ نیازمند منبع ]}
• جمع‌بندی پایان به انتها، با استفاده از نوعی « فیلد یکپارچگی داده »، که امکان تشخیص خرابی داده‌ها را فراهم می‌کند (و در صورت وجود افزونگی در استخر، بازیابی). می توان از 3 هش استفاده کرد که برای سرعت (فلچر)، استانداردسازی و امنیت ( SHA256 ) و هش نمک ( Skein ) بهینه شده است. ^[69]
• فشرده سازی سیستم فایل شفاف پشتیبانی از LZJB ، gzip ، ^[70] LZ4 و Zstd .
• شستشوی هوشمند و نقره سازی مجدد (همگام سازی مجدد). ^[71]
• به اشتراک گذاری بار و فضا در بین دیسک های موجود در استخر. ^[72]
• بلوک‌های Ditto: تکرار داده‌های قابل تنظیم در هر فایل سیستم، با صفر، یک یا دو نسخه اضافی در هر نوشتن برای داده‌های کاربر، و با همان تعداد پایه کپی به اضافه یک یا دو نسخه برای ابرداده (با توجه به اهمیت ابرداده) درخواست می‌شود. ^[73] اگر استخر چندین دستگاه داشته باشد، ZFS سعی می‌کند روی دستگاه‌های مختلف تکثیر کند. بلوک های Ditto در درجه اول یک محافظت اضافی در برابر بخش های خراب هستند، نه در برابر خرابی کامل دیسک. ^[74]
• طراحی ZFS (کپی در نوشتن + سوپر بلوک ها) هنگام استفاده از دیسک هایی با حافظه پنهان نوشتن فعال است، اگر موانع نوشتن را رعایت کنند. ^{[ نیازمند منبع ]} این ویژگی ایمنی و افزایش عملکرد را در مقایسه با برخی از سیستم های فایل دیگر فراهم می کند. ^{[ به گفته چه کسی؟ ]}
• در Solaris، زمانی که کل دیسک ها به یک استخر ZFS اضافه می شوند، ZFS به طور خودکار حافظه پنهان نوشتن آنها را فعال می کند. زمانی که ZFS فقط برش‌های مجزا از دیسک را مدیریت می‌کند، این کار انجام نمی‌شود، زیرا نمی‌داند که آیا سایر برش‌ها توسط سیستم‌های فایل ایمن غیرنوشتن کش مدیریت می‌شوند، مانند UFS . ^{[ نیاز به نقل از ]} پیاده‌سازی FreeBSD به لطف چارچوب GEOM خود می‌تواند فلاش دیسک را برای پارتیشن‌ها مدیریت کند و بنابراین از این محدودیت رنج نمی‌برد. ^{[ نیازمند منبع ]}
• محدودیت‌های سهمیه برای هر کاربر، هر گروه، هر پروژه و هر مجموعه داده. ^[75]
• رمزگذاری سیستم فایل از Solaris 11 Express، ^[76] و OpenZFS (ZoL) 0.8. ^[58] (در برخی از سیستم‌های دیگر ZFS می‌تواند از دیسک‌های رمزگذاری‌شده برای اثر مشابه استفاده کند؛ GELI در FreeBSD می‌تواند به این روش برای ایجاد فضای ذخیره‌سازی کاملاً رمزگذاری‌شده ZFS استفاده شود).
• استخرها را می توان در حالت فقط خواندنی وارد کرد.
• بازیابی اطلاعات با بازگرداندن کل تراکنش ها در زمان وارد کردن zpool امکان پذیر است. ^{[ نیازمند منبع ]}
• عکس های فوری را می توان به صورت دستی یا خودکار گرفت. نسخه‌های قدیمی‌تر داده‌های ذخیره‌شده که حاوی آن‌ها هستند، می‌توانند به‌عنوان فایل سیستم‌های فقط خواندنی کامل نمایش داده شوند. آنها همچنین می توانند به عنوان نسخه های تاریخی فایل ها و پوشه ها در صورت استفاده با CIFS (همچنین به عنوان SMB، Samba یا اشتراک فایل شناخته می شوند) در معرض دید قرار گیرند. این به‌عنوان «نسخه‌های قبلی»، «کپی‌های سایه VSS»، یا «تاریخچه فایل» در ویندوز ، یا AFP و «Apple Time Machine» در دستگاه‌های اپل شناخته می‌شود. ^[77]
• دیسک ها را می توان به عنوان "یدکی" علامت گذاری کرد. یک مخزن داده را می توان با فعال کردن یک دیسک یدکی و شروع به تبدیل مجدد داده هایی که روی دیسک مشکوک بود در صورت نیاز روی آن تنظیم کرد تا به طور خودکار و شفاف خطاهای دیسک را مدیریت کند.

محدودیت ها

• از سولاریس 10 به‌روزرسانی 11 و سولاریس 11.2، نه کاهش تعداد vdev‌های سطح بالا در یک استخر امکان‌پذیر بود، به جز دستگاه‌های یدکی داغ، حافظه پنهان و گزارش، و نه در غیر این صورت ظرفیت استخر را کاهش داد. ^[78] گفته شد که این قابلیت در سال 2007 در حال توسعه است. ^[79] بهبودهایی برای کاهش vdevs در OpenZFS در دست توسعه است. ^[80] کوچک‌شدن آنلاین با حذف vdev‌های سطح بالای غیر زائد از زمانی که Solaris 11.4 در آگوست 2018 منتشر شد ^[81] و OpenZFS (ZoL) 0.8 که در می 2019 منتشر شد، پشتیبانی می‌شود. ^[58]
• از سال 2008 ^[update]امکان افزودن دیسک به عنوان ستون به RAID Z، RAID Z2 یا RAID Z3 vdev وجود نداشت. با این حال، می‌توان یک RAID Z vdev جدید ایجاد کرد و به zpool اضافه کرد. ^[82]
• برخی از پیکربندی‌های RAID تودرتوی سنتی، مانند RAID 51 (آینه‌ای از گروه‌های RAID 5)، بدون برخی ابزارهای شخص ثالث، در ZFS قابل تنظیم نیستند. ^[83] Vdev ها فقط می توانند از دیسک ها یا فایل های خام تشکیل شوند، نه از سایر vdev ها، با استفاده از دستورات مدیریت پیش فرض ZFS. ^[84] با این حال، یک استخر ZFS به طور موثر یک نوار (RAID 0) در سراسر vdev های خود ایجاد می کند، بنابراین معادل RAID 50 یا RAID 60 رایج است.
• پیکربندی مجدد تعداد دستگاه‌ها در یک vdev سطح بالا مستلزم کپی کردن داده‌ها در حالت آفلاین، از بین بردن استخر، و ایجاد مجدد استخر با پیکربندی جدید vdev سطح بالا است، به جز اضافه کردن افزونگی اضافی به یک آینه موجود، که می‌تواند در هر زمان انجام شود. یا اگر همه vdev های سطح بالا آینه هایی با افزونگی کافی هستند، دستور zpool split ^[85] را می توان برای حذف یک vdev از هر vdev سطح بالا در استخر استفاده کرد، و یک استخر دوم با داده های یکسان ایجاد کرد.

بازیابی اطلاعات

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

ZFS مدرن در طول زمان به طور قابل توجهی در این وضعیت بهبود یافته است و به این کار ادامه می دهد:

• حذف یا خرابی ناگهانی دستگاه های کش دیگر باعث از دست رفتن استخر نمی شود. (در بدترین حالت، از دست دادن ZIL ممکن است تراکنش‌های بسیار اخیر را از دست بدهد، اما ZIL معمولاً تراکنش‌های اخیر را بیش از چند ثانیه ذخیره نمی‌کند. از دست دادن حافظه پنهان L2ARC بر داده‌ها تأثیر نمی‌گذارد.)
• اگر استخر غیرقابل نصب باشد، نسخه‌های مدرن ZFS سعی می‌کنند آخرین نقطه ثابتی را که می‌توان در آن استخر را بازیابی کرد، به قیمت از دست دادن برخی از جدیدترین تغییرات در محتویات شناسایی کرد. کپی در نوشتن به این معنی است که نسخه‌های قدیمی‌تر داده‌ها، از جمله رکوردهای سطح بالا و ابرداده، ممکن است همچنان وجود داشته باشند، حتی اگر جایگزین شوند، و اگر چنین باشد، می‌توان مجموعه را بر اساس آنها به حالت ثابت بازگرداند. هر چه داده‌ها قدیمی‌تر باشند، احتمال بیشتری وجود دارد که حداقل برخی از بلوک‌ها بازنویسی شده باشند و برخی از داده‌ها غیرقابل بازیابی باشند، بنابراین محدودیتی در توانایی استخر برای بازگرداندن وجود دارد.
• به‌طور غیررسمی، ابزارهایی برای بررسی دلیل عدم توانایی ZFS در نصب استخر وجود دارد و کاربر یا توسعه‌دهنده را در مورد تغییرات دستی مورد نیاز برای نصب استخر راهنمایی می‌کند. این موارد شامل استفاده از zdb (اشکال زدایی ZFS) برای یافتن یک نقطه قابل واردات معتبر در استخر، استفاده از dtrace یا مشابه برای شناسایی مشکلی که باعث خرابی مانت می‌شود، یا دور زدن دستی بررسی‌های سلامتی که باعث توقف فرآیند نصب می‌شود و اجازه نصب استخر آسیب‌دیده را می‌دهد. .
• از مارس 2018 ^[update]، طیف وسیعی از روش‌های بهبود یافته به‌تدریج در OpenZFS در حال گسترش هستند. این موارد عبارتند از: ^[86]

• بازسازي کد، و اطلاعات تشخيصي و اشکال‌زدايي دقيق‌تر در مورد خرابي‌هاي مانت، براي ساده‌سازي تشخيص و رفع مشکلات استخر خراب؛
• توانایی اعتماد یا عدم اعتماد به پیکربندی استخر ذخیره شده. این به ویژه قدرتمند است، زیرا اجازه می‌دهد یک استخر حتی زمانی که vdev‌های سطح بالا مفقود یا معیوب هستند، زمانی که داده‌های سطح بالا مشکوک هستند، نصب شود، و همچنین در صورتی که تغییر به مشکل مرتبط بود، به عقب برگردد. هنگامی که مخزن خراب نصب شد، فایل های قابل خواندن را می توان برای ایمنی کپی کرد، و ممکن است معلوم شود که داده ها را می توان حتی برای vdev های از دست رفته، با استفاده از کپی های ذخیره شده در جای دیگری در استخر، بازسازی کرد.
• توانایی رفع وضعیتی که یک دیسک مورد نیاز در یک استخر، به طور تصادفی حذف شده و به یک استخر دیگر اضافه شده است، و باعث از دست دادن ابرداده مربوط به اولین استخر می شود که غیرقابل خواندن می شود.

OpenZFS و ZFS

شرکت اوراکل توسعه عمومی ZFS و OpenSolaris را پس از خرید Sun در سال 2010 متوقف کرد . برخی از توسعه دهندگان آخرین نسخه عمومی OpenSolaris را به عنوان پروژه Illumos منتشر کردند. به دلیل مزایای قابل توجه موجود در ZFS، آن را به چندین پلتفرم مختلف با ویژگی ها و دستورات مختلف منتقل شده است. برای هماهنگی تلاش های توسعه و جلوگیری از تکه تکه شدن، OpenZFS در سال 2013 تاسیس شد.

به گفته مت آرنس، یکی از معماران اصلی ZFS، بیش از 50 درصد از کد OpenSolaris ZFS اصلی از سال 2019 در OpenZFS با مشارکت‌های جامعه جایگزین شده است و «Oracle ZFS» و «OpenZFS» را از نظر سیاسی و فناوری ناسازگار می‌کند. ^[87]

محصولات تجاری و متن باز

• 2008: Sun خطی از لوازم ذخیره سازی سری 7000 مبتنی بر ZFS را ارسال کرد. ^[88]
• 2013: Oracle سری ZS3 از فیلرهای مبتنی بر ZFS را ارسال کرد و با یکی از آنها مقام اول را در معیار SPC-2 به دست آورد. ^[89]
• 2013: iXsystems دستگاه‌های NAS مبتنی بر ZFS به نام FreeNAS (که اکنون TrueNAS CORE نامیده می‌شود) را برای SOHO و TrueNAS برای شرکت ارسال کرد. ^{[90] [91]}
• 2014: Netgear خطی ​​از دستگاه های NAS مبتنی بر ZFS به نام ReadyDATA را ارسال کرد که برای استفاده در سازمان طراحی شده است. ^[92]
• 2015: rsync.net یک پلتفرم ذخیره سازی ابری را معرفی کرد که به مشتریان اجازه می دهد zpool خود را تهیه کنند و داده ها را با استفاده از ارسال و دریافت zfs وارد و صادر کنند. ^{[93] [94]}
• 2020: iXsystems توسعه یک نرم‌افزار ابرهمگرا مبتنی بر ZFS به نام TrueNAS SCALE را برای SOHO و TrueNAS برای شرکت آغاز کرد. ^[91]

Oracle Corporation، منبع بسته و فورکینگ (از سال 2010)

در ژانویه 2010، شرکت اوراکل Sun Microsystems را خریداری کرد و به سرعت توزیع OpenSolaris و مدل توسعه منبع باز را متوقف کرد. ^{[95] [96]} در آگوست 2010، اوراکل ارائه به‌روزرسانی‌های عمومی برای کد منبع مخزن سیستم عامل/شبکه ​​سولاریس را متوقف کرد و عملاً Solaris 11 را به یک سیستم عامل اختصاصی منبع بسته تبدیل کرد. ^[97]

در پاسخ به تغییر چشم‌انداز Solaris و OpenSolaris، پروژه illumos از طریق وبینار ^[98] در روز پنجشنبه، 3 آگوست 2010، به عنوان تلاش جامعه برخی از مهندسان اصلی Solaris برای ادامه توسعه نسخه منبع باز Solaris راه‌اندازی شد و تکمیل شد. منبع باز آن بخش هایی که قبلاً توسط Sun منبع باز نیستند. ^[99] illumos به عنوان یک بنیاد، بنیاد Illumos، در ایالت کالیفرنیا به عنوان یک انجمن تجاری 501(c)6 تاسیس شد. طرح اولیه به صراحت بیان می کرد که illumos توزیع یا فورک نخواهد بود. با این حال، پس از اینکه اوراکل اعلام کرد که OpenSolaris را متوقف می‌کند، برنامه‌هایی برای فورک نسخه نهایی Solaris ON انجام شد که به illumos اجازه می‌دهد تا به یک سیستم عامل خاص خود تبدیل شوند. ^[100] به عنوان بخشی از OpenSolaris، یک نسخه منبع باز از ZFS بنابراین در illumos یکپارچه بود.

ZFS به طور گسترده در پلتفرم های متعدد و همچنین سولاریس مورد استفاده قرار گرفت. بنابراین، در سال 2013، هماهنگی کار توسعه بر روی نسخه منبع باز ZFS به یک پروژه چتر، OpenZFS منتقل شد . چارچوب OpenZFS به هر طرف علاقه‌مند اجازه می‌دهد تا به طور مشترک پایگاه کد اصلی ZFS را توسعه دهد، در حالی که به صورت جداگانه هر کد اضافی خاصی را که ZFS برای عملکرد و ادغام در سیستم‌های خود به آن نیاز دارد، حفظ کند.

تاریخچه نسخه

توجه: نسخه سولاریس در حال توسعه توسط Sun از زمان انتشار Solaris 10 در سال 2005 ، با نام رمز «نوادا» بود و از همان پایگاه کد OpenSolaris مشتق شده بود . "Solaris Nevada" نام رمز نسل بعدی سیستم عامل Solaris است که در نهایت جانشین Solaris 10 می شود و این کد جدید به طور متوالی در نسخه های جدید OpenSolaris "Nevada" کشیده شد. ^[101] OpenSolaris اکنون متوقف شده است و OpenIndiana از آن جدا شده است . ^{[102] [103]} ساخت نهایی (b134) OpenSolaris توسط Oracle (2010-نوامبر-12) به عنوان مسیر ارتقاء به Solaris 11 Express منتشر شد .

پشتیبانی از سیستم عامل

فهرست سیستم‌عامل‌ها، توزیع‌ها و افزونه‌هایی که از ZFS پشتیبانی می‌کنند، نسخه zpool که از آن پشتیبانی می‌کند و ساخت Solaris که بر اساس آن‌ها ساخته شده‌اند (در صورت وجود):

همچنین ببینید

• مقایسه فایل سیستم ها
• لیست فایل سیستم ها
• نسخه سیستم فایل – فهرست سیستم های فایل نسخه سازی

یادداشت ها

1. در حالی که RAID 7 یک سطح RAID استاندارد نیست، به عنوان یک اصطلاح جامع برای هر پیکربندی RAID برابری بیش از 3 پیشنهاد شده است ^[38]

مراجع

1. "ZFS چیست؟". راهنمای مدیریت Oracle Solaris ZFS . اوراکل. بایگانی شده از نسخه اصلی در 4 مارس 2016 . بازبینی شده در 29 دسامبر 2015 .
2. «ZFS در مجوز لینوکس». GitHub . بازبینی شده در 17 مه 2020 .
3. «پروژه OpenZFS راه اندازی شد». LWN.net ​17 سپتامبر 2013. بایگانی شده از نسخه اصلی در 4 اکتبر 2013 . بازیابی شده در 1 اکتبر 2013 .
4. «اعلان OpenZFS». OpenZFS . 17 سپتامبر 2013. بایگانی شده از نسخه اصلی در 2 آوریل 2018 . بازبینی شده در 19 سپتامبر 2013 .
5. open-zfs.org /History بایگانی شده در 24 دسامبر 2013، در Wayback Machine "OpenZFS جانشین واقعاً منبع باز پروژه ZFS است [...] اثرات فورک (2010 تا به امروز)"
6. شان مایکل کرنر (۱۸ سپتامبر ۲۰۱۳). "LinuxCon: OpenZFS ذخیره سازی منبع باز را به جلو می برد". infostor.com. بایگانی شده از نسخه اصلی در 14 مارس 2014 . بازبینی شده در 9 اکتبر 2013 .
7. «پروژه OpenZFS راه اندازی شد». LWN.net ​17 سپتامبر 2013. بایگانی شده از نسخه اصلی در 11 اکتبر 2016 . بازیابی شده در 1 اکتبر 2013 .
8. «OpenZFS – جوامعی که روی کد و ویژگی های ZFS همکاری می کنند». freebsdnews.net. 23 سپتامبر 2013. بایگانی شده از نسخه اصلی در 14 اکتبر 2013 . بازبینی شده در 14 مارس 2014 .
9. «سؤالات متداول Starline ZFS». استارلاین . بازبینی شده در 20 ژوئیه 2024 .
10. "19.4. zfs Administration". www.freebsd.org . بایگانی شده از نسخه اصلی در 23 فوریه 2017 . بازبینی شده در 22 فوریه 2017 .
11. سالوس، پیتر (1994). ربع قرن یونیکس . ادیسون-وسلی. صص 199-200. شابک 0-201-54777-5.
12. «SunOS و Solaris چیست؟». پایگاه دانش . خدمات فناوری دانشگاه ایندیانا 20 مه 2013 . بازبینی شده در 10 نوامبر 2014 .
13. براون، دیوید. "گفتگو با جف بونویک و بیل مور". صف ACM . انجمن ماشین های محاسباتی بایگانی شده از نسخه اصلی در 16 ژوئیه 2011 . بازبینی شده در 17 نوامبر 2015 .
14. "ZFS: آخرین کلمه در سیستم های فایل". سان میکروسیستم. 14 سپتامبر 2004. بایگانی شده از نسخه اصلی در 28 آوریل 2006 . بازیابی شده در 30 آوریل 2006 .
15. متیو آرنس (1 نوامبر 2011). "10 سالگی ZFS". بایگانی شده از نسخه اصلی در 28 ژوئن 2016 . بازبینی شده در ۲۴ جولای ۲۰۱۲ .
16. Bonwick، Jeff (31 اکتبر 2005). "ZFS: آخرین کلمه در سیستم های فایل". blogs.oracle.com . بایگانی شده از نسخه اصلی در 19 ژوئن 2013 . بازبینی شده در 22 ژوئن 2013 .
17. «Sun یک سالگرد موفقیت آمیز OpenSolaris را جشن می گیرد». سان میکروسیستم. 20 ژوئن 2006. بایگانی شده از نسخه اصلی در 28 سپتامبر 2008 . بازبینی شده در 30 آوریل 2018 .
18. مایکل سینگر (۲۵ ژانویه ۲۰۰۵). "خورشید سولاریس را می شکافد". اینترنت نیوز دات کام . بازیابی شده در 12 آوریل 2010 .
19. «سؤالات متداول ZFS در OpenSolaris.org». سان میکروسیستم. بایگانی شده از نسخه اصلی در 15 مه 2011 . بازیابی شده در 18 مه 2011 . بزرگترین پیشوند SI که ما دوست داشتیم "zetta" بود ("yotta" نامعلوم بود)
20. جف بونویک (۳ مه ۲۰۰۶). "شما می گویید زتا، من می گویم زتا". وبلاگ جف بونویک . بایگانی شده از نسخه اصلی در 23 فوریه 2017 . بازبینی شده در 21 آوریل 2017 . بنابراین ما در نهایت تصمیم گرفتیم که نام را به ZFS برگردانیم، که هیچ چیزی را نشان نمی دهد.
21. «Oracle و NetApp شکایت های ZFS را رد کردند». theregister.co.uk. 9 سپتامبر 2010. بایگانی شده از نسخه اصلی در 9 سپتامبر 2017 . بازبینی شده در 24 دسامبر 2013 .
22. سیستم فایل Extended (Ext) دارای ساختار ابرداده است که از UFS کپی شده است. "رمی کارت (مصاحبه، آوریل 1998)". انجمن آوریل. 19 آوریل 1999. بایگانی شده از نسخه اصلی در 4 فوریه 2012 . بازیابی شده در 8 فوریه 2012 .(به زبان فرانسه)
23. ویجایان پرابهاکاران (2006). "سیستم های فایل آهنی" (PDF) . دکترای فلسفه در علوم کامپیوتر . دانشگاه ویسکانسین-مدیسون بایگانی شده (PDF) از نسخه اصلی در 29 آوریل 2011 . بازیابی شده در 9 ژوئن 2012 .
24. «برابری از دست رفته و برابری دوباره به دست آمد». بایگانی شده از نسخه اصلی در 15 ژوئن 2010 . بازیابی شده در 29 نوامبر 2010 .
25. «تجزیه و تحلیل خرابی داده ها در پشته ذخیره سازی» (PDF) . بایگانی شده (PDF) از نسخه اصلی در 15 ژوئن 2010 . بازیابی شده در 29 نوامبر 2010 .
26. «تأثیر خرابی دیسک بر DBMS منبع باز» (PDF) . بایگانی شده (PDF) از نسخه اصلی در 15 ژوئن 2010 . بازیابی شده در 29 نوامبر 2010 .
27. کاداو، عاصم؛ راجیمواله، آبیشک. "تحلیل قابلیت اطمینان ZFS" (PDF) . بایگانی شده (PDF) از نسخه اصلی در 21 سپتامبر 2013 . بازبینی شده در 19 سپتامبر 2013 .
28. یوپو ژانگ؛ آبیشک راجیمواله; آندریا آرپاچی-دوسو ؛ Remzi H. Arpaci-Dusseau (2010). "یکپارچگی داده های انتها به انتها برای سیستم های فایل: مطالعه موردی ZFS" (PDF) . کنفرانس USENIX در مورد فن آوری های فایل و ذخیره سازی . CiteSeerX 10.1.1.154.3979 . S2CID  5722163. ویکی داده  Q111972797 . بازیابی شده در 6 دسامبر 2010 . 
29. لارابل، مایکل. "معیارسازی ZFS و UFS در FreeBSD در مقابل EXT4 و Btrfs در لینوکس". Phoronix Media 2012. بایگانی شده از نسخه اصلی در 29 نوامبر 2016 . بازیابی شده در 21 نوامبر 2012 .
30. لارابل، مایکل. "آیا HAMMER DragonFlyBSD می تواند با Btrfs، ZFS رقابت کند؟". Phoronix Media 2012. بایگانی شده از نسخه اصلی در 29 نوامبر 2016 . بازیابی شده در 21 نوامبر 2012 .
31. Bonwick, Jeff (8 دسامبر 2005). "یکپارچگی داده سرتاسر ZFS". blogs.oracle.com . بایگانی شده از نسخه اصلی در 3 آوریل 2012 . بازبینی شده در 19 سپتامبر 2013 .
32. کوک، تیم (16 نوامبر 2009). "نمایش خود درمانی ZFS". blogs.oracle.com . بایگانی شده از نسخه اصلی در 12 اوت 2011 . بازیابی شده در 1 فوریه 2015 .
33. رنچ، ریچارد (4 مه 2007). "ZFS، کپی ها و حفاظت از داده ها". blogs.oracle.com . بایگانی شده از نسخه اصلی در 18 اوت 2016 . بازبینی شده در 2 فوریه 2015 .
34. "zpoolconcepts.7 — اسناد OpenZFS". openzfs.github.io . بازبینی شده در 5 آوریل 2023 .
35. «ZFS Without Tears: استفاده از ZFS بدون حافظه ECC». www.csparks.com . دسامبر 2015. بایگانی شده از نسخه اصلی در 13 ژانویه 2021 . بازبینی شده در 16 ژوئن 2020 .
36. wdc.custhelp.com. "تفاوت بین نسخه دسکتاپ و درایوهای نسخه RAID (Enterprise)". بایگانی شده از نسخه اصلی در 5 ژانویه 2015 . بازیابی شده در 8 سپتامبر 2011 .
37. Bonwick, Jeff (17 نوامبر 2005). "RAID-Z". وبلاگ جف بونویک . وبلاگ های اوراکل بایگانی شده از نسخه اصلی در 16 دسامبر 2014 . بازیابی شده در 1 فوریه 2015 .
38. Leventhal, Adam (17 دسامبر 2009). "RAID سه برابری و فراتر از آن". صف . 7 (11): 30. doi : 10.1145/1661785.1670144 .
39. «عملکرد، ظرفیت و یکپارچگی ZFS Raidz». calomel.org . بایگانی شده از نسخه اصلی در 27 نوامبر 2017 . بازبینی شده در 23 ژوئن 2017 .
40. «چرا RAID 6 در سال 2019 کار نمی‌کند». ZDNet . 22 فوریه 2010. بایگانی شده از نسخه اصلی در 31 اکتبر 2014 . بازبینی شده در 26 اکتبر 2014 .
41. "هیچ معادلی از ابزار fsck برای ZFS وجود ندارد. این ابزار به طور سنتی دو هدف را انجام می دهد، یکی تعمیر سیستم فایل و دیگری اعتبار سنجی سیستم فایل." "بررسی یکپارچگی سیستم فایل ZFS". اوراکل. بایگانی شده از نسخه اصلی در 31 ژانویه 2013 . بازیابی شده در 25 نوامبر 2012 .
42. "ZFS Scrubs". freenas.org. بایگانی شده از نسخه اصلی در 27 نوامبر 2012 . بازبینی شده در 25 نوامبر 2012 .
43. "همچنین باید قبل از تعویض دستگاه ها یا کاهش موقت افزونگی استخر یک اسکراب را اجرا کنید تا مطمئن شوید که همه دستگاه ها در حال حاضر فعال هستند." "راهنمای بهترین روش های ZFS". solarisinternals.com. بایگانی شده از نسخه اصلی در 5 سپتامبر 2015 . بازیابی شده در 25 نوامبر 2012 .
44. جف بونویک. "ذخیره سازی 128 بیتی: آیا بالا هستید؟". oracle.com ​بایگانی شده از نسخه اصلی در 29 مه 2015 . بازبینی شده در 29 مه 2015 .
45. «ZFS: اقیانوس را می جوشاند، ماه را مصرف می کند (وبلاگ دیو بریلهارت)». بایگانی شده از نسخه اصلی در 8 دسامبر 2015 . بازبینی شده در 19 دسامبر 2015 .
46. «راهنمای مدیریت Solaris ZFS». شرکت اوراکل بایگانی شده از نسخه اصلی در 13 ژانویه 2021 . بازیابی شده در 11 فوریه 2011 .
47. «رمزگذاری سیستم‌های فایل ZFS». بایگانی شده از نسخه اصلی در 23 ژوئن 2011 . بازیابی شده در 2 مه 2011 .
48. «داشتن کیک ایمن و کلون کردن آن (معروف به رمزگذاری + حذف با ZFS)». بایگانی شده از نسخه اصلی در 29 مه 2013 . بازیابی شده در 9 اکتبر 2012 .
49. «ZFS – Debian Wiki». wiki.debian.org . بایگانی شده از نسخه اصلی در 8 سپتامبر 2019 . بازیابی شده در 10 دسامبر 2019 .
50. «پیشنهاد: هشدارهایی را در مورد استفاده از رمزگذاری بومی zfs به همراه send/recv در تولید اضافه کنید». Github . Github . بازبینی شده در 15 اوت 2024 .
51. "PSA: ZFS هنگام استفاده از رمزگذاری بومی و ارسال/recv دارای یک اشکال خرابی داده است". Reddit . Reddit . بازبینی شده در 15 اوت 2024 .
52. "تجزیه ZFS: راه حل های بلند مدت". Github . Github . بازبینی شده در 15 اوت 2024 .
53. "بهترین شیوه ها برای جلوگیری از تکه تکه شدن ZFS چیست". سیستم های لارنس سیستم های لارنس بازبینی شده در 15 اوت 2024 .
54. «Solaris ZFS استخرهای ذخیره سازی ترکیبی را فعال می کند—موانع اقتصادی و عملکرد را از بین می برد» (PDF) . Sun.com 7 سپتامبر 2010. بایگانی شده (PDF) از نسخه اصلی در 17 اکتبر 2011 . بازیابی شده در 4 نوامبر 2011 .
55. گرگ، برندان. "ZFS L2ARC". وبلاگ برندان Dtrace.org. بایگانی شده از نسخه اصلی در 6 نوامبر 2011 . بازیابی شده در 5 اکتبر 2012 .
56. گرگ، برندان (8 اکتبر 2009). "استخر ذخیره سازی ترکیبی: سرعت های بالا". وبلاگ برندان Dtrace.org. بایگانی شده از نسخه اصلی در 5 آوریل 2016 . بازبینی شده در 15 اوت 2017 .
57. «Solaris ZFS Performance Tuning: Synchronous Writes and the ZIL». Constantin.glez.de. 20 جولای 2010. بایگانی شده از نسخه اصلی در 23 ژوئن 2012 . بازیابی شده در 5 اکتبر 2012 .
58. "Release zfs-0.8.0". GitHub . OpenZFS. 23 مه 2019 . بازبینی شده در 3 ژوئیه 2021 .
59. «ZFS On-Disk Specification» (PDF) . Sun Microsystems, Inc. 2006. بایگانی شده از نسخه اصلی (PDF) در 30 دسامبر 2008.بخش 2.4 را ببینید.
60. "RAIDZ - اسناد OpenZFS". openzfs.github.io . بازبینی شده در 9 فوریه 2023 .
61. اریک اسپرول (21 مه 2009). "آجیل و پیچ و مهره ZFS". slideshare.net. صص 30-31. بایگانی شده از نسخه اصلی در 22 ژوئن 2014 . بازبینی شده در 8 ژوئن 2014 .
62. «ZFS Deduplication». blogs.oracle.com . بایگانی شده از نسخه اصلی در ۲۴ دسامبر ۲۰۱۹ . بازبینی شده در 25 نوامبر 2019 .
63. گری سیمز (4 ژانویه 2012). "ساخت فضای ذخیره سازی متصل به شبکه مبتنی بر ZFS با استفاده از FreeNAS 8". آموزش TrainSignal . TrainSignal, Inc. بایگانی شده از نسخه اصلی (وبلاگ) در 7 می 2012 . بازیابی شده در 9 ژوئن 2012 .
64. ری ون دولسون (مه 2011). "[zfs-discuss] خلاصه: الزامات حافظه Deduplication". zfs-discuss لیست پستی. بایگانی شده از نسخه اصلی در ۲۵ آوریل ۲۰۱۲.
65. «ZFSTuningGuide». بایگانی شده از نسخه اصلی در 16 ژانویه 2012 . بازیابی شده در 3 ژانویه 2012 .
66. کریس ملور (۱۲ اکتبر ۲۰۱۲). "GreenBytes پمپر VDI کلون کامل را به صدا در می آورد". ثبت نام . بایگانی شده از نسخه اصلی در ۲۴ مارس ۲۰۱۳ . بازبینی شده در 29 اوت 2013 .
67. کریس ملور (۱ ژوئن ۲۰۱۲). "تازه وارد جعبه خود را بیرون می آورد، قصد دارد آن را ارزان به همه واردان بفروشد." ثبت نام . بایگانی شده از نسخه اصلی در 12 اوت 2013 . بازبینی شده در 29 اوت 2013 .
68. کریس ملور (۱۱ دسامبر ۲۰۱۴). «ددوپ، ددوپ... ددوپ، ددوپ، ددوپ: اوراکل الماس ZFS را صیقل می دهد». ثبت نام . بایگانی شده از نسخه اصلی در 7 ژوئیه 2017 . بازبینی شده در 17 دسامبر 2014 .
69. "Checksums و استفاده از آنها در ZFS". github.com ​2 سپتامبر 2018. بایگانی شده از نسخه اصلی در 19 جولای 2019 . بازبینی شده در 11 جولای 2019 .
70. «راهنمای مدیریت Solaris ZFS». فصل 6 مدیریت سیستم های فایل ZFS . بایگانی شده از نسخه اصلی در 5 فوریه 2011 . بازیابی شده در 17 مارس 2009 .
71. «آینه دودی». blogs.oracle.com . 2 مه 2006. بایگانی شده از نسخه اصلی در 16 دسامبر 2011 . بازبینی شده در 13 فوریه 2012 .
72. «تخصیص بلوک ZFS». وبلاگ جف بونویک . 4 نوامبر 2006. بایگانی شده از نسخه اصلی در 2 نوامبر 2012 . بازیابی شده در 23 فوریه 2007 .
73. «دیتو بلوک - دافع نوار شگفت‌انگیز». وب‌لاگ بیت‌های متحرک . 12 مه 2006. بایگانی شده از نسخه اصلی در 26 می 2013 . بازیابی شده در 1 مارس 2007 .
74. «افزودن دیسک‌های جدید و رفتار بلوک مشابه». بایگانی شده از نسخه اصلی در 23 اوت 2011 . بازیابی شده در 19 اکتبر 2009 .
75. «OpenSolaris.org». سان میکروسیستم. بایگانی شده از نسخه اصلی در 8 مه 2009 . بازیابی شده در 22 مه 2009 .
76. «چیزهای جدید در Solaris 11 Express 2010.11» (PDF) . اوراکل. بایگانی شده (PDF) از نسخه اصلی در 16 نوامبر 2010 . بازیابی شده در 17 نوامبر 2010 .
77. "10. اشتراک گذاری — فهرست مطالب راهنمای کاربر FreeNAS 9.3". doc.freenas.org . بایگانی شده از نسخه اصلی در ۷ ژانویه ۲۰۱۷ . بازبینی شده در 23 فوریه 2017 .
78. «شناسه اشکال 4852783: کاهش ظرفیت استخر». پروژه OpenSolaris. بایگانی شده از نسخه اصلی در 29 ژوئن 2009 . بازیابی شده در 28 مارس 2009 .
79. گوبلز، ماریو (19 آوریل 2007). "حذف دائمی vdevs از یک استخر". zfs-discuss (لیست پستی).^{[ پیوند مرده دائمی ]} پیوند بایگانی بایگانی شده در 13 ژانویه 2021، در Wayback Machine
80. Chris Siebenmann اطلاعات مربوط به حذف vdev در آینده بایگانی شده در ۱۱ اوت ۲۰۱۶، در Wayback Machine ، دانشگاه تورنتو، وبلاگ، نقل قول: اعلامیه غیررسمی توییتر توسط Alex Reece بایگانی شده در ۱۱ اوت ۲۰۱۶، در Wayback Machine
81. «ویژگی های مدیریت داده – چه جدید در Oracle® Solaris 11.4». بایگانی شده از نسخه اصلی در ۲۴ سپتامبر ۲۰۱۹ . بازیابی شده در 9 اکتبر 2019 .
82. «Expand-O-Matic RAID Z». آدام لونتال. 7 آوریل 2008. بایگانی شده از نسخه اصلی در 28 دسامبر 2011 . بازبینی شده در 16 آوریل 2012 .
83. "ZFS Toy". SourceForge.net . بازبینی شده در 12 آوریل 2022 .
84. "zpoolconcepts(7)". اسناد OpenZFS . OpenZFS. 2 ژوئن 2021 . بازبینی شده در 12 آوریل 2021 . دستگاه‌های مجازی را نمی‌توان تودرتو کرد، بنابراین یک دستگاه مجازی mirror یا raidz فقط می‌تواند حاوی فایل‌ها یا دیسک‌ها باشد. آینه آینه (یا ترکیبات دیگر) مجاز نیست.
85. "zpool(1M)". Download.oracle.com. 11 ژوئن 2010. بایگانی شده از نسخه اصلی در 13 ژانویه 2021 . بازیابی شده در 4 نوامبر 2011 .
86. «بازیابی اطلاعات ZFS توربوشارژ». بایگانی شده از نسخه اصلی در 29 نوامبر 2018 . بازبینی شده در 29 نوامبر 2018 .
87. «ZFS و OpenZFS». iXSystems ​بازبینی شده در 18 مه 2020 .
88. «Sun وسایل ذخیره‌سازی خودش را راه‌اندازی می‌کند». techworld.com.au. 11 نوامبر 2008. بایگانی شده از نسخه اصلی در 13 نوامبر 2013 . بازبینی شده در 13 نوامبر 2013 .
89. کریس ملور (۲ اکتبر ۲۰۱۳). "ماهیچه های اوراکل با فیلر سنگین ZFS در بالای معیار قرار می گیرند". theregister.co.uk. بایگانی شده از نسخه اصلی در 7 ژوئیه 2017 . بازبینی شده در 7 جولای 2014 .
90. «دستگاه ذخیره سازی یکپارچه ZFS ساخته شده در Silicon Valley توسط iXsystem». ixsystems.com. بایگانی شده از نسخه اصلی در 3 ژوئیه 2014 . بازبینی شده در 7 جولای 2014 .
91. "TrueNAS 12 & TrueNAS SCALE رسما اینجا هستند!". ixsystems.com ​بازیابی شده در 2 ژانویه 2021 .
92. «ReadyDATA 516 – ذخیره سازی شبکه یکپارچه» (PDF) . netgear.com. بایگانی شده (PDF) از نسخه اصلی در 15 ژوئیه 2014 . بازبینی شده در 7 جولای 2014 .
93. جیم سالتر (۱۷ دسامبر ۲۰۱۵). "rsync.net: تکثیر ZFS به ابر بالاخره رسید - و سریع است". arstechnica.com. بایگانی شده از نسخه اصلی در ۲۲ اوت ۲۰۱۷ . بازبینی شده در ۲۱ اوت ۲۰۱۷ .
94. rsync.net, Inc. "Cloud Storage with ZFS ارسال و دریافت از طریق SSH". rsync.net. بایگانی شده از نسخه اصلی در 21 ژوئیه 2017 . بازبینی شده در ۲۱ اوت ۲۰۱۷ .
95. استیون استالیون / اوراکل (۱۳ اوت ۲۰۱۰). "به روز رسانی در SXCE". گرایش های شمایل شکنی بایگانی شده از نسخه اصلی در 9 نوامبر 2020 . بازبینی شده در 30 آوریل 2018 .
96. آلاسدایر لومسدن. "OpenSolaris لغو شد، با Solaris 11 Express جایگزین می شود". osol-discuss (لیست پستی). بایگانی شده از نسخه اصلی در 16 اوت 2010 . بازبینی شده در 24 نوامبر 2014 .
97. سولاریس هنوز کاملاً باز است، اما توزیع OpenSolaris مرده است. بایگانی‌شده در ۵ سپتامبر ۲۰۱۷، در Wayback Machine در Ars Technica توسط رایان پل (۱۶ اوت ۲۰۱۰)
98. Garrett D'Amore (3 اوت 2010). "Illumos - Hope and Light Springs New - ارائه شده توسط Garrett D'Amore" (PDF) . illumos.org . بازیابی شده در 3 آگوست 2010 .
99. "Whither OpenSolaris؟ Illumos Takes Up the Mantle". بایگانی شده از نسخه اصلی در 26 سپتامبر 2015.
100. Garrett D'Amore (13 اوت 2010). "دست ممکن است مجبور شود" . بازبینی شده در 14 نوامبر 2013 .
101. "در حالی که تحت کنترل Sun Microsystems بود، هر دو هفته یک بار عکس های فوری از Solaris Nevada (نام رمز نسل بعدی سیستم عامل Solaris که در نهایت جایگزین Solaris 10 می شود) وجود داشت و این کد جدید سپس در عکس های فوری پیش نمایش OpenSolaris جدید در Genunix قرار گرفت. .org نسخه های پایدار OpenSolaris بر اساس [ sic ] این بیلدهای نوادا است. لارابل، مایکل. "به نظر می رسد اوراکل پشت OpenSolaris خواهد ایستاد". فورونیکس مدیا. بایگانی شده از نسخه اصلی در 29 نوامبر 2016 . بازیابی شده در 21 نوامبر 2012 .
102. لیوبونچیچ، ایگور (23 مه 2011). "OpenIndiana - هنوز امیدی وجود دارد". DistroWatch . بایگانی شده از نسخه اصلی در 27 اکتبر 2012 . بازیابی شده در 21 نوامبر 2012 .
103. "به پروژه OpenIndiana خوش آمدید!". پروژه OpenIndiana. 10 سپتامبر 2010. بایگانی شده از نسخه اصلی در 27 نوامبر 2012 . بازیابی شده در 14 سپتامبر 2010 .
104. «نسخه‌های استخر ZFS». شرکت اوراکل 2022. بایگانی شده از نسخه اصلی در 21 دسامبر 2022 . بازیابی شده در 1 ژانویه 2023 .

کتابشناسی

• واتانابه، اسکات (23 نوامبر 2009). Solaris ZFS Essentials (ویرایش اول). سالن پرنتیس ص 256. شابک 978-0-13-700010-4. بایگانی شده از نسخه اصلی در ۱ اکتبر ۲۰۱۲.

لینک های خارجی

• چنگال آره! ظهور و توسعه Illumos - نمایش اسلایدی که بیشتر تاریخچه Solaris، تصمیم به منبع باز توسط Sun، ایجاد ZFS، و رویدادهایی که باعث بسته شدن و فورک شدن آن پس از خرید اوراکل شده است را پوشش می دهد.
• بهترین سیستم فایل ابری قبل از وجود ابر ایجاد شده است (بایگانی شده در 15 دسامبر 2018)
• مقایسه آینه سازی SVM و آینه سازی ZFS
• توزیع EON ZFS Storage (NAS).
• یکپارچگی داده سرتاسر برای سیستم های فایل: مطالعه موردی ZFS
• ZFS - سیستم فایل زتابایت (بایگانی شده در 28 فوریه 2013)
• ZFS و RAID-Z: Über-FS؟
• ZFS: The Last Word In File Systems، اثر جف بونویک و بیل مور (بایگانی شده در 29 اوت 2017)
• تجسم گزارش قصد ZFS (ZIL)، آوریل 2013، توسط آرون توپونسه
• ویژگی های illumos از جمله OpenZFS
  • صفحه ویکی قبلی با پیوندهای بیشتر: شروع به کار با ZFS، 15 سپتامبر 2014 (بایگانی شده در 30 دسامبر 2018)، بخشی از مستندات illumos