دومین مصاحبه با ادوارد شیشکین، توسعه دهنده فایل سیستم Reiser4 منتشر شده است.
برای شروع، لطفاً به خوانندگان یادآوری کنید که کجا و برای چه کسی کار می کنید.
من به عنوان یک معمار اصلی ذخیره سازی در Huawei Technologies، مرکز تحقیقات آلمان کار می کنم. در بخش مجازی سازی با جنبه های مختلف ذخیره سازی داده ها سر و کار دارم. فعالیت های من مربوط به سیستم عامل خاصی نیست.
آیا در حال حاضر به شاخه اصلی هسته متعهد هستید؟
خیلی به ندرت و فقط در صورتی که کارفرمای من آن را بخواهد. آخرین بار حدود سه سال پیش بود، من وصله هایی را برای افزایش توان ذخیره سازی به اشتراک گذاشته شده در هاست ها با استفاده از پروتکل 9p ارسال کردم (نام دیگر این تجارت VirtFS است). در اینجا باید یک نکته مهم را ذکر کرد: اگرچه من مدت زیادی است که با لینوکس کار می کنم، اما هرگز طرفدار آن نبوده ام، یعنی مانند هر چیز دیگری "به طور مساوی نفس می کشم". به خصوص اگر متوجه نقصی شدم حداکثر یکبار می توانم به آن اشاره کنم. و به این ترتیب که می توانید پس از آن کسی را دنبال کنید و آنها را متقاعد کنید - این اتفاق نمی افتد.
به یاد دارم آخرین بار، ده سال پیش، شما کاملاً از سبک توسعه هسته انتقاد داشتید. از دیدگاه شما (یا شاید شرکتی)، آیا چیزی تغییر کرده است، آیا جامعه پاسخگوتر شده است یا خیر؟ اگر نه، به نظر شما مقصر کیست؟
من هیچ تغییر مثبتی ندیدهام. مشکل اصلی جامعه جایگزینی علم با فناوریهای سیاسی، روابط شخصی، نظر اکثریت، پوپولیسم، توصیههای «صداهای درونی»، سازشهای فاسد - هر چیزی جز علم - است. علم کامپیوتر، مهم نیست چطور به آن نگاه کنید، قبل از هر چیز، یک علم دقیق است. و اگر کسی شروع به اعلام معنایی برای ۲x۲ کند که با ۴ متفاوت است، تحت عنوان «Linux یا تحت هر شرایط دیگری، بعید است که چیزی جز آسیب به همراه داشته باشد.
همه مشکلات در درجه اول به دلیل بی کفایتی و عدم آموزش تصمیم گیرندگان است. اگر مدیری ناتوان باشد، نمی تواند تصمیمی عینی و کافی بگیرد. اگر او هم بی فرهنگ باشد، نمی تواند متخصص شایسته ای پیدا کند که به او مشاوره درست بدهد. با احتمال زیاد، انتخاب بر عهده کلاهبردار است که می گوید "چیزهای به ظاهر درست". یک محیط فاسد همیشه حول رهبران تنها نالایق ایجاد می شود. گذشته از این، تاریخ در این زمینه استثنایی نمی شناسد و جامعه روشن ترین تایید آن است.
پیشرفت در توسعه Btrfs را چگونه ارزیابی می کنید؟ آیا این FS از شر بیماری های دوران کودکی خلاص شد؟ چگونه آن را برای خود قرار می دهید - به عنوان یک FS "برای خانه" یا برای استفاده شرکتی نیز؟
از شرش خلاص نشدم همه چیزهایی که 11 سال پیش به آن اشاره کردم امروز نیز مطرح است. یکی از مشکلات Btrfs که آن را برای نیازهای جدی نامناسب می کند، مشکل فضای خالی است. من حتی در مورد این واقعیت صحبت نمی کنم که در شرایطی که هر FS دیگری فضای خالی زیادی را روی پارتیشن نشان می دهد از کاربر خواسته می شود برای یک دیسک جدید به فروشگاه اجرا شود. ناتوانی در تکمیل یک عملیات در حجم منطقی به دلیل کمبود فضای آزاد نیز بدترین چیز نیست. بدترین چیز این است که یک کاربر غیرمجاز تقریباً همیشه می تواند هر سهمیه دیسک را دور بزند و در مدت زمان نسبتاً کوتاهی همه را از فضای آزاد محروم کند.
به نظر میرسد این شکلی است (برای هسته آزمایش شده است) Linux ۵.۱۲). در یک سیستم تازه نصب شده، اسکریپتی اجرا میشود که فایلهایی با نامهای خاص را در دایرکتوری خانگی در یک حلقه ایجاد میکند، دادهها را با فاصلههای مشخص روی آنها مینویسد و سپس این فایلها را حذف میکند. پس از یک دقیقه اجرای این اسکریپت، هیچ اتفاق غیرعادی رخ نمیدهد. پس از پنج دقیقه، فضای اشغال شده روی پارتیشن کمی افزایش مییابد. پس از دو تا سه ساعت، به ۵۰٪ (از مقدار اولیه ۱۵٪) میرسد. و پس از پنج تا شش ساعت، اسکریپت با خطای "هیچ فضای خالی روی پارتیشن وجود ندارد" از کار میافتد. پس از این، دیگر نمیتوانید حتی یک فایل ۴K را روی پارتیشن خود بنویسید.
یک موقعیت جالب رخ می دهد: شما در نهایت چیزی روی پارتیشن ننوشتید و تمام فضای خالی (حدود 85٪) در جایی ناپدید شد. تجزیه و تحلیل بخشی که در معرض چنین حمله ای قرار می گیرد، گره های درختی زیادی را نشان می دهد که فقط حاوی یک آیتم (یک شی مجهز به یک کلید) با اندازه چند بایت هستند. یعنی محتوایی که قبلاً 15٪ از فضای دیسک را اشغال می کرد معلوم شد که به طور مساوی روی کل پارتیشن "لکه دار" شده است به طوری که جایی برای نوشتن یک فایل جدید وجود ندارد ، زیرا کلید آن بزرگتر از همه موارد موجود است و رایگان است. بلوک های روی پارتیشن تمام شده اند.
علاوه بر این، همه اینها قبلاً در پیکربندی اولیه Btrfs (بدون هیچ عکس فوری، حجم فرعی و غیره) اتفاق میافتد، و مهم نیست که چگونه تصمیم میگیرید بدنههای فایل را در آن FS ذخیره کنید (بهعنوان «قطعهها» در یک درخت، یا به صورت وسعت. بلوک های فرمت نشده) - نتیجه نهایی یکسان خواهد بود.
شما نمی توانید سایر سیستم های فایل بالادستی را در معرض چنین حمله ای قرار دهید (مهم نیست آنها به شما چه می گویند). علت مشکل را خیلی وقت پیش توضیح دادم: این یک انحراف کامل از مفهوم B-tree در Btrfs است که امکان انحطاط خود به خود یا عمدی آن را فراهم می کند. به ویژه، تحت بارهای خاص، سیستم فایل شما به طور مداوم در حین کار خود به خود، بدون کمک خارجی، "از هم می پاشد". واضح است که انواع فرآیندهای پسزمینه «فشار دادن» تنها در دسکتاپهای فردی باعث صرفهجویی در روز میشوند.
روی موارد جمعی سرورها یک مهاجم همیشه میتواند از آنها "جلوتر" برود. مدیر سیستم حتی نمیتواند تشخیص دهد که دقیقاً چه کسی از او سوءاستفاده میکرده است. سریعترین راه برای رفع این مشکل در Btrfs، بازیابی ساختار یک B-tree معمولی است، یعنی طراحی مجدد قالب دیسک و بازنویسی بخش قابل توجهی از کد Btrfs. این کار، شامل اشکالزدایی، 8 تا 10 سال طول خواهد کشید، البته به شرطی که توسعهدهندگان به طور دقیق از مقالات اصلی در مورد الگوریتمها و ساختارهای داده مربوطه پیروی کرده باشند و "تلفن خراب" را بازی نکرده باشند، همانطور که مرسوم است (و در ... تشویق میشود).Linux راه".
در اینجا ما همچنین باید زمان مورد نیاز برای توسعه دهندگان را برای درک همه اینها اضافه کنیم. اینجاست که کار سخت تر می شود. به هر حال 10 سال برایشان کافی نبود که بفهمند. خوب، تا آن زمان نمی توانید به معجزه امیدوار باشید. این به شکل یک گزینه نصب «که من و شما در مورد آن نمیدانستیم» یا به شکل وصلهای که «فقط یک موضوع تجاری» برای آماده کردن است، اتفاق نمیافتد. برای هر «رفع» شتابزده، سناریوی جدیدی از انحطاط ارائه خواهم کرد. B-trees یکی از موضوعات مورد علاقه من است و باید بگویم که این سازه ها تحمل آزادی با خود را ندارند!
چگونه Btrfs را برای خودم قرار دهم؟ به عنوان چیزی که مطلقاً نمی توان آن را یک سیستم فایل نامید، چه رسد به استفاده از آن. زیرا طبق تعریف، FS یک زیرسیستم سیستم عامل است که مسئول مدیریت مؤثر منبع "فضای دیسک" است که در مورد Btrfs نمی بینیم. خوب تصور کنید برای اینکه دیر سر کار نمانید برای خرید ساعت به فروشگاه آمده اید و به جای ساعت یک کباب پز برقی با تایمر حداکثر 30 دقیقه به شما فروخته اند. بنابراین، وضعیت Btrfs از این هم بدتر است.
با نگاهی به لیست های پستی، اغلب با این بیانیه مواجه می شوم که مدیریت موثر فضای دیسک به دلیل ارزان بودن درایوها دیگر مرتبط نیست. این کاملا مزخرف است. بدون یک مدیر فضای دیسک موثر، سیستم عامل آسیب پذیر و غیرقابل استفاده خواهد شد. صرف نظر از ظرفیت دیسک های روی دستگاه شما.
من می خواهم در مورد قطع پشتیبانی Btrfs در RHEL نظر بدهم.
در اینجا چیز خاصی برای اظهار نظر وجود ندارد، همه چیز کاملاً واضح است. آنها همچنین آن را به عنوان "پیش نمایش فناوری" داشتند. بنابراین، من این «پیشنمایش» را انجام ندادم. اجازه ندهید این برچسب برای همیشه آویزان شود! اما آنها نمی توانند با پشتیبانی کامل محصولی با طراحی جانبی معیوب عرضه کنند. RHEL یک شرکت است، یعنی روابط کالا و پول تجویز شده است. رد هت نمی تواند کاربران را مانند لیست پستی Btrfs مورد آزار و اذیت قرار دهد. فقط وضعیت را تصور کنید: مشتری که پولی را که به سختی به دست آورده برای دیسک و همچنین شما برای پشتیبانی پرداخت کرده است، میخواهد بفهمد پس از اینکه چیزی را یادداشت نکرد، فضای دیسک او کجا رفته است. در این مورد چه جوابی به او خواهید داد؟
به علاوه. مشتریان ردهت شامل بانک ها و صرافی های بزرگ و شناخته شده هستند. تصور کنید اگر بر اساس آسیبپذیری ذکر شده در Btrfs در معرض حملات DoS قرار گیرند، چه اتفاقی میافتد. به نظر شما چه کسی مسئول این کار است؟ به کسانی که می خواهند انگشت خود را به سمت خط مجوز GPL بگیرند، جایی که نوشته شده است نویسنده هیچ مسئولیتی ندارد، بلافاصله می گویم: "پنهان کن!" کلاه قرمزی جواب می دهد و به گونه ای که کافی به نظر نمی رسد! اما میدانم که Red Hat با توجه به تیم قوی مهندسین QA که در زمان خود فرصت همکاری نزدیک با آنها را داشتم، با این نوع مشکل مواجه نیست.
چرا برخی از شرکت ها به حمایت از Btrfs در محصولات سازمانی خود ادامه می دهند؟
توجه داشته باشید که پیشوند «Enterprise» در نام محصول معنای زیادی ندارد. Enterprise معیاری از مسئولیت است که در رابطه قراردادی با مشتری تعبیه شده است. من فقط یک Enterprise مبتنی بر GNU میشناسم.Linux — این RHEL است. به نظر من، هر چیز دیگری فقط ظاهر سازمانی دارد، اما اینطور نیست. و در نهایت، اگر تقاضا برای چیزی وجود داشته باشد، همیشه عرضه هم وجود خواهد داشت (در مورد ما، این همان "پشتیبانی" است که قبلاً ذکر شد). تقاضا میتواند برای تقریباً همه چیز باشد، از جمله نرمافزارهای غیرقابل استفاده. اینکه این تقاضا چگونه شکل میگیرد و چه کسی آن را تقویت میکند، موضوع کاملاً دیگری است.
بنابراین، پس از اینکه شایعه شد فیسبوک Btrfs را روی سرورهای خود مستقر کرده است، من هیچ نتیجهگیری عجولانهای نمیکنم. علاوه بر این، آدرسهای آن سرورها به دلایلی که در بالا ذکر شد، توصیه میکنم آن را با دقت مخفی نگه دارید.
چرا اخیراً تلاش زیادی برای پاکسازی کد XFS انجام شده است؟ از این گذشته، در ابتدا این یک سیستم فایل شخص ثالث است و ext4 برای مدت طولانی پایدار بوده و تداومی نسبت به نسخه های قبلی به همان اندازه پایدار دارد. Red Hat چه علاقه ای به XFS دارد؟ آیا منطقی است که به طور فعال دو سیستم فایل را که از نظر هدف مشابه هستند توسعه دهیم - ext4 و XFS؟
یادم نیست چه انگیزه ای برای این کار ایجاد شد. کاملاً ممکن است که ابتکار عمل از سوی مشتریان کلاه قرمزی انجام شده باشد. به یاد دارم که تحقیقاتی از این دست انجام شد: در برخی از سیستم های فایل از بالادست، تعداد عظیمی از اشیاء در درایوهای پیشرفته نسل جدید ایجاد شد. با توجه به نتایج، XFS بهتر از ext4 رفتار کرد. بنابراین آنها شروع به تبلیغ آن به عنوان امیدوار کننده ترین کردند. در هر صورت، من در اینجا دنبال هیچ چیز هیجان انگیزی نمی گردم.
برای من، مثل این است که صابون را جایگزین بالش کرده باشند. هیچ فایده ای برای توسعه ext4 و XFS وجود ندارد. هر دو به صورت موازی و هر یک از آنها را انتخاب کنید. هیچ چیز خوبی از این اتفاق نخواهد افتاد. اگرچه در طبیعت اغلب مواقعی پیش می آید که پتانسیل زیادی برای رشد وجود دارد، اما جایی برای رشد وجود ندارد. در این مورد، رشدهای جدید عجیب و غریب و زشتی بوجود می آیند که همه انگشت خود را به سمت آنها نشان می دهند ("اوه، ببین، چه چیزی را در این زندگی نخواهی دید!").
آیا فکر می کنید با ظهور توابع رمزگذاری در ext4، F2FS (بدون ذکر RAID در Btrfs) مسئله نقض لایه (به معنای منفی) حل شده است؟
به طور کلی معرفی هر سطحی و تصمیم گیری در مورد عدم تخطی از آنها معمولاً یک امر سیاستی است و من در اینجا متعهد نمی شوم در مورد چیزی اظهار نظر کنم. جنبه های عینی نقض لایه برای کسی جالب نیست، اما ما می توانیم برخی از آنها را با استفاده از مثال نقض "از بالا" در نظر بگیریم، یعنی پیاده سازی در FS عملکردی که از قبل در لایه بلوک وجود دارد. چنین "نقض" تنها با استثناهای نادر توجیه می شود. برای هر یک از این موارد، ابتدا باید دو چیز را ثابت کنید: اینکه واقعاً مورد نیاز است و اینکه طراحی سیستم با انجام این کار آسیبی نخواهد دید.
برای مثال، mirroring، که به طور سنتی یک فعالیت برای لایه بلوک بوده است، پیاده سازی در سطح سیستم فایل منطقی است. به دلایل مختلف. به عنوان مثال، خرابی داده های "بی صدا" (پوسیدگی بیت) در درایوهای دیسک رخ می دهد. این زمانی است که دستگاه به درستی کار میکند، اما دادههای بلوک به طور غیرمنتظرهای تحت تأثیر کوانتوم گامای سخت ساطع شده توسط یک کوازار دور و غیره آسیب میبینند. بدترین چیز این است که این بلوک یک بلوک سیستم FS (سوپر بلوک، بلوک بیت مپ، گره درخت ذخیره سازی و غیره) باشد، زیرا مطمئناً منجر به وحشت هسته می شود.
لطفا توجه داشته باشید که آینه های ارائه شده توسط لایه بلوک (به اصطلاح RAID 1) شما را از این مشکل نجات نمی دهند. خوب، واقعاً: کسی باید چکسامها را بررسی کند و در صورت خرابی نسخه را بخواند؟ علاوه بر این، منطقی است که نه تنها همه چیز، بلکه فقط ابرداده را منعکس کنیم. برخی از داده های مهم (به عنوان مثال، فایل های اجرایی برنامه های کاربردی مهم) را می توان به عنوان ابرداده ذخیره کرد. در این مورد، آنها همان تضمین های ایمنی را دریافت می کنند. منطقی است که حفاظت از داده های باقی مانده را به زیرسیستم های دیگر (شاید حتی برنامه های کاربردی کاربر) واگذار کنیم - ما تمام شرایط لازم را برای این کار فراهم کرده ایم.
چنین آینههای «اقتصادی» حق وجود دارند و فقط میتوانند به طور مؤثر در سطح سیستم فایل سازماندهی شوند. در غیر این صورت، نقض لایهبندی بهخاطر برخی مزایای میکروسکوپی، یک زیرسیستم را با کدهای تکراری درهم میریزد. یک مثال قابل توجه در این مورد پیاده سازی RAID-5 با استفاده از FS است. چنین راه حل هایی (RAID / LVM خود در سیستم فایل) دومی را از نظر معماری می کشد. همچنین در اینجا لازم به ذکر است که نقض لایه بندی توسط انواع مختلف کلاهبرداران بازاریابی "در جریان قرار می گیرد". در غیاب هیچ ایده ای، عملکردی که مدت هاست در سطوح همسایه پیاده سازی شده است به زیرسیستم ها اضافه می شود، این به عنوان یک ویژگی بسیار مفید جدید ارائه می شود و به طور فعال تحت فشار قرار می گیرد.
Reiser4 به نقض سطوح "از پایین" متهم شد. بر اساس این واقعیت که سیستم فایل مانند همه سیستم های دیگر یکپارچه نیست، اما ماژولار است، یک فرض غیرمستند ایجاد شد که آنچه را که سطح بالاتر (VFS) باید انجام دهد، انجام می دهد.
آیا می توان در مورد مرگ ReiserFS v3.6 و مثلا JFS صحبت کرد؟ اخیراً آنها تقریباً هیچ توجهی در هسته دریافت نکرده اند. آیا آنها منسوخ شده اند؟
در اینجا باید تعریف کنیم که مرگ یک محصول نرم افزاری به چه معناست. از یک طرف، آنها با موفقیت مورد استفاده قرار می گیرند (در نهایت برای این ساخته شده اند)، به این معنی که آنها زندگی می کنند. از طرف دیگر، من نمی توانم برای JFS صحبت کنم (من چیز زیادی نمی دانم)، اما ReiserFS (v3) برای انطباق با روندهای جدید بسیار دشوار است (در عمل آزمایش شده است). این بدان معنی است که در آینده توسعه دهندگان نه به آن، بلکه به آنهایی که سازگاری آنها راحت تر است توجه خواهند کرد. از این طرف معلوم می شود که افسوس از نظر معماری مرده است. من اصلاً مفهوم "از نظر اخلاقی منسوخ" را دستکاری نمی کنم. به عنوان مثال، برای کمد لباس به خوبی اعمال می شود، اما برای محصولات نرم افزاری نه. در چیزی مفهوم حقارت و برتری وجود دارد. من کاملاً می توانم بگویم که ReserFS v3 اکنون در همه چیز از Reiser4 پایین تر است، اما در برخی از انواع حجم کاری از همه FS های بالادستی دیگر برتری دارد.
آیا از توسعه FS Tux3 و HAMMER/HAMMER2 (FS برای DragonFly BSD) اطلاع دارید؟
بله، ما می دانیم. در Tux3 من زمانی به فناوری عکس های فوری آنها علاقه مند بودم (به اصطلاح "نشانگرهای نسخه")، اما در Reiser4 به احتمال زیاد مسیر دیگری را طی خواهیم کرد. من مدت زیادی است که به پشتیبانی از عکس های فوری فکر می کنم و هنوز تصمیم نگرفته ام که چگونه آنها را برای حجم های ساده Reiser4 پیاده سازی کنم. واقعیت این است که تکنیک شمارنده مرجع "تنبل" جدید پیشنهاد شده توسط اوحد روده فقط برای درختان B کار می کند. ما آنها را نداریم. برای آن دسته از ساختارهای داده ای که در Reiesr4 استفاده می شوند، شمارنده های "تنبل" تعریف نشده اند - برای معرفی آنها، باید مسائل الگوریتمی خاصی را حل کرد، که هنوز کسی آن ها را بر عهده نگرفته است.
به گزارش HAMMER: مقاله ای از سازنده خواندم. علاقه مند نیست. دوباره درختان B. این ساختار داده به طرز ناامیدکننده ای منسوخ شده است. ما آن را در قرن گذشته رها کردیم.
تقاضای رو به رشد برای FS های خوشه ای شبکه مانند CephFS/GlusterFS/و غیره را چگونه ارزیابی می کنید؟ آیا این تقاضا به معنای تغییر اولویت های توسعه دهندگان به سمت FS شبکه و عدم توجه کافی به FS محلی است؟
بله، چنین تغییری در اولویت ها اتفاق افتاده است. توسعه سیستم های فایل محلی راکد شده است. افسوس، انجام کاری قابل توجه برای حجم های محلی اکنون بسیار دشوار است و همه نمی توانند آن را انجام دهند. هیچ کس نمی خواهد در توسعه آنها سرمایه گذاری کند. این تقریباً مانند درخواست از یک سازمان تجاری برای اختصاص پول برای تحقیقات ریاضی است - بدون هیچ اشتیاق آنها از شما می پرسند که چگونه می توانید از یک قضیه جدید درآمد کسب کنید. اکنون یک FS محلی چیزی است که به طور جادویی "خارج از جعبه" ظاهر می شود و "همیشه باید کار کند"، و اگر کار نکرد، باعث غرغرهای بی دلیل می شود مانند: "بله، آنها به چه فکر می کنند!"
از این رو عدم توجه به FS محلی، اگرچه هنوز کار زیادی در آن زمینه وجود دارد. و بله، همه به ذخیره سازی توزیع شده روی آورده اند که بر اساس سیستم های فایل محلی موجود ساخته شده است. الان خیلی مد شده عبارت Big Data برای بسیاری باعث افزایش آدرنالین می شود و آن را با کنفرانس ها، کارگاه ها، حقوق های کلان و غیره مرتبط می کند.
اصولا پیاده سازی سیستم فایل شبکه در فضای هسته به جای فضای کاربر چقدر معقول است؟
رویکردی بسیار معقول که هنوز در هیچ کجا اجرا نشده است. به طور کلی، این سوال که یک سیستم فایل شبکه باید در چه فضایی پیادهسازی شود یک "شمشیر دولبه" است. خوب، بیایید به یک مثال نگاه کنیم. مشتری داده ها را روی یک دستگاه از راه دور ثبت کرد. آنها به صورت صفحات کثیف به حافظه پنهان صفحه او افتادند. این کار برای یک سیستم فایل شبکه "دروازه نازک" در فضای هسته است. سپس سیستم عامل دیر یا زود از شما می خواهد که آن صفحات را روی دیسک بنویسید تا آنها را آزاد کنید. سپس ماژول FS شبکه IO-forwarding (ارسال) وارد بازی می شود. تعیین می کند که این صفحات به کدام ماشین سرور (گره سرور) بروند.
سپس پشته شبکه بر عهده می گیرد (و همانطور که می دانیم در فضای هسته پیاده سازی می شود). سپس، گره سرور آن بسته را با داده یا ابرداده دریافت میکند و به ماژول ذخیرهسازی پشتیبان (یعنی FS محلی که در فضای هسته عمل میکند) دستور میدهد تا همه این موارد را ثبت کند. بنابراین، ما این سوال را به جایی کاهش داده ایم که ماژول های "ارسال" و "دریافت" باید کار کنند. اگر هر یک از آن ماژول ها در فضای کاربر اجرا شود، این امر به ناچار منجر به تغییر متن (به دلیل نیاز به استفاده از خدمات هسته) می شود. تعداد این سوئیچ ها به جزئیات پیاده سازی بستگی دارد.
اگر تعداد زیادی از این سوئیچ ها وجود داشته باشد، ظرفیت ذخیره سازی (عملکرد I/O) کاهش می یابد. اگر فضای ذخیره سازی پشتیبان شما از دیسک های کند تشکیل شده باشد، افت قابل توجهی نخواهید داشت. اما اگر دیسکهای سریع دارید (SSD، NVRAM، و غیره)، در این صورت تغییر زمینه در حال حاضر به یک "گلوگاه" تبدیل میشود و با صرفهجویی در تعویض متن، عملکرد را میتوان به میزان قابل توجهی افزایش داد. راه استاندارد برای صرفه جویی در هزینه، انتقال ماژول ها به فضای هسته است. به عنوان مثال، ما دریافتیم که انتقال سرور 9p از QEMU به هسته در ماشین میزبان منجر به افزایش سه برابری عملکرد VirtFS می شود.
البته این یک FS شبکه نیست، اما به طور کامل ماهیت چیزها را منعکس می کند. نقطه ضعف این بهینه سازی، مشکلات حمل و نقل است. برای برخی، دومی ممکن است حیاتی باشد. به عنوان مثال، GlusterFS اصلا ماژولی در هسته ندارد. به لطف این، اکنون بر روی بسیاری از سیستم عامل ها، از جمله NetBSD کار می کند.
FS های محلی چه مفاهیمی را می توانند از شبکه های شبکه قرض بگیرند و بالعکس؟
امروزه، FS های شبکه، به عنوان یک قاعده، دارای افزونه هایی بر روی FS های محلی هستند، بنابراین من کاملا نمی دانم که چگونه می توانید چیزی را از دومی قرض بگیرید. خب، در واقع، بیایید شرکتی متشکل از 4 کارمند را در نظر بگیریم، که در آن هرکس کار خود را انجام می دهد: یکی توزیع می کند، دیگری می فرستد، سومی دریافت می کند، چهارمی فروشگاه می کند. و این سؤال که شرکت چه چیزی می تواند از کارمند خود که آن را ذخیره می کند قرض بگیرد، به نوعی نادرست به نظر می رسد (قبلاً آنچه را که می توانست برای مدت طولانی از او قرض گرفته باشد داشته است).
اما FS های محلی چیزهای زیادی برای یادگیری از FS های شبکه دارند. اولا، شما باید از آنها یاد بگیرید که چگونه حجم های منطقی را در سطح بالایی جمع آوری کنید. در حال حاضر به اصطلاح سیستمهای فایل محلی «پیشرفته» حجمهای منطقی را منحصراً با استفاده از فناوری «دستگاه مجازی» وام گرفته شده از LVM جمعآوری میکنند (همان نقض لایهبندی عفونی که برای اولین بار در ZFS پیادهسازی شد). به عبارت دیگر، ترجمه آدرس های مجازی (اعداد بلوک) به آدرس های واقعی و برگشتی در سطح پایینی اتفاق می افتد (یعنی پس از اینکه سیستم فایل درخواست I/O را صادر کرد).
لطفاً توجه داشته باشید که افزودن و حذف دستگاهها به حجمهای منطقی (نه آینهها) که روی لایه بلوک چیده شدهاند، منجر به مشکلاتی میشود که تأمینکنندگان چنین «ویژگیهایی» نسبتاً در مورد آن سکوت میکنند. من در مورد تکه تکه شدن در دستگاه های واقعی صحبت می کنم، که می توانند به مقادیر هیولایی برسند، در حالی که در یک دستگاه مجازی همه چیز خوب است. با این حال، افراد کمی به دستگاه های مجازی علاقه مند هستند: همه به آنچه در دستگاه های واقعی شما اتفاق می افتد علاقه مند هستند. اما FS مانند ZFS (و همچنین هر FS در ارتباط با LVM) فقط با دستگاه های دیسک مجازی کار می کند (آدرس های دیسک مجازی را از بین موارد رایگان اختصاص دهید، این دستگاه های مجازی را یکپارچه سازی کنید و غیره). و آنها هیچ ایده ای ندارند که در دستگاه های واقعی چه اتفاقی می افتد!
حالا تصور کنید که در دستگاه مجازی تکه تکه شدن صفر است (یعنی فقط یک گستره غول پیکر در آنجا زندگی می کنید)، یک دیسک به حجم منطقی خود اضافه می کنید و سپس یک دیسک تصادفی دیگر را از حجم منطقی خود حذف می کنید و سپس تعادل مجدد را برقرار می کنید. و بارها. تصور این که در دستگاه مجازی همچنان به همان میزان زندگی کنید، سخت نیست، اما در دستگاه های واقعی چیز خوبی نخواهید دید.
بدترین چیز این است که شما حتی قادر به اصلاح این وضعیت نیستید! تنها کاری که می توانید در اینجا انجام دهید این است که از سیستم فایل بخواهید دستگاه مجازی را یکپارچه سازی کند. اما او به شما خواهد گفت که همه چیز در آنجا عالی است - فقط یک حد وجود دارد، تکه تکه شدن صفر است و بهتر از این نمی تواند باشد! بنابراین، حجم های منطقی مرتب شده در سطح بلوک برای افزودن/حذف مکرر دستگاه ها در نظر گرفته نشده اند. در یک راه خوب، شما فقط باید یک بار یک حجم منطقی را در سطح بلوک جمع آوری کنید، آن را به سیستم فایل بدهید و سپس هیچ کار دیگری با آن انجام ندهید.
علاوه بر این، ترکیب زیرسیستمهای مستقل FS+LVM اجازه نمیدهد تا ماهیت متفاوت درایوهایی که حجمهای منطقی از آنها جمعآوری میشوند، در نظر گرفته شود. در واقع، فرض کنید یک حجم منطقی از HDD و دستگاه های حالت جامد جمع آوری کرده اید. اما پس از آن اولی نیاز به یکپارچه سازی دارد و دومی نه. برای دومی، باید درخواست های رد کردن را صادر کنید، اما برای اولی، نه و غیره. با این حال، در این ترکیب، نشان دادن چنین انتخابی بسیار دشوار است.
توجه داشته باشید که پس از ایجاد LVM خود در سیستم فایل، وضعیت خیلی بهتر نمی شود. علاوه بر این، با انجام این کار، در واقع به چشم انداز بهبود آن در آینده پایان می دهید. این خیلی بد است. انواع مختلف درایوها می توانند روی یک دستگاه زندگی کنند. و اگر سیستم فایل بین آنها تمایز قائل نشود، پس چه کسی این کار را خواهد کرد؟
مشکل دیگر در انتظار به اصطلاح است. سیستمهای فایل «Write-Anywhere» (اگر مدل تراکنشی مناسب را در حین نصب مشخص کرده باشید، شامل Reiser4 نیز میشود). چنین سیستم های فایلی باید ابزارهای یکپارچه سازی را ارائه دهند که در قدرت خود بی سابقه هستند. و مدیر حجم پایین در اینجا کمکی نمی کند، بلکه فقط مانع می شود. واقعیت این است که با چنین مدیری، FS شما نقشه بلوک های رایگان تنها یک دستگاه - مجازی را ذخیره می کند. بر این اساس، شما فقط می توانید یک دستگاه مجازی را یکپارچه سازی کنید. این به این معنی است که یکپارچه سازی شما برای مدت طولانی روی یک فضای بزرگ از آدرس های مجازی کار می کند.
و اگر کاربران زیادی دارید که بازنویسیهای تصادفی انجام میدهند، تأثیر مفید چنین یکپارچهسازی به صفر میرسد. سیستم شما ناگزیر شروع به کند شدن خواهد کرد و فقط باید دستان خود را در مقابل تشخیص ناامیدکننده "طراحی شکسته" جمع کنید. چندین یکپارچه سازی که در فضای آدرس یکسانی اجرا می شوند فقط با یکدیگر تداخل دارند. اگر نقشه بلوک های رایگان خود را برای هر دستگاه واقعی حفظ کنید، موضوع کاملاً متفاوت است. این به طور موثر فرآیند یکپارچه سازی را موازی می کند.
اما این کار تنها در صورتی امکان پذیر است که یک مدیر حجم منطقی سطح بالا داشته باشید. سیستم های فایل محلی با چنین مدیرانی قبلاً وجود نداشت (حداقل، من در مورد آنها نمی دانم). فقط سیستم های فایل شبکه (به عنوان مثال GlusterFS) چنین مدیرانی داشتند. مثال بسیار مهم دیگر ابزار بررسی یکپارچگی حجم (fsck) است. اگر نقشه مستقل بلوکهای آزاد خود را برای هر زیرجلد ذخیره کنید، روش بررسی یک حجم منطقی میتواند به طور موثر موازی شود. به عبارت دیگر، حجم های منطقی با مدیران سطح بالا مقیاس بهتری دارند.
علاوه بر این، با مدیران حجم پایین نمیتوانید عکسهای فوری کامل را سازماندهی کنید. با سیستمهای فایل مشابه LVM و ZFS، فقط میتوانید عکسهای فوری محلی بگیرید، اما نه عکسهای فوری سراسری. عکسهای فوری محلی به شما این امکان را میدهند که فوراً فقط عملیات معمولی فایل را به عقب برگردانید. و هیچ کس در آنجا عملیات با حجم های منطقی (افزودن/حذف دستگاه ها) را به عقب بر نمی گرداند. بیایید با یک مثال به این موضوع نگاه کنیم. در یک مقطع زمانی، وقتی حجم منطقی دو دستگاه A و B حاوی 100 فایل دارید، یک عکس فوری از سیستم S میگیرید و سپس صد فایل دیگر ایجاد میکنید.
پس از آن، دستگاه C را به حجم خود اضافه میکنید و در نهایت سیستم خود را به Snapshot S برمیگردانید. سؤال: حجم منطقی شما پس از بازگشت به S شامل چند فایل و دستگاه است؟ همانطور که حدس زده اید 100 فایل وجود دارد، اما 3 دستگاه وجود دارد - اینها همان دستگاه های A، B و C هستند، اگرچه در زمان ایجاد عکس فوری فقط دو دستگاه در سیستم وجود داشت (A و B ). عملیات افزودن دستگاه C برنگشت و اگر اکنون دستگاه C را از رایانه حذف کنید، داده های شما را خراب می کند، بنابراین قبل از حذف باید ابتدا یک عملیات گران قیمت برای حذف دستگاه از ولوم منطقی تعادل مجدد انجام دهید. تمام دادهها را از دستگاه C به دستگاههای A و B پراکنده میکند. اما اگر FS شما از عکسهای فوری سراسری پشتیبانی میکند، چنین تعادلی لازم نیست و پس از بازگشت فوری به S، میتوانید با خیال راحت دستگاه C را از رایانه حذف کنید.
بنابراین، عکسهای فوری جهانی خوب هستند، زیرا به شما امکان میدهند از حذف (افزودن) پرهزینه یک دستگاه از حجم منطقی (به حجم منطقی) با مقدار زیادی داده (البته، اگر به یاد داشته باشید که از سیستم خود عکس فوری بگیرید) جلوگیری کنید. در زمان مناسب). اجازه دهید به شما یادآوری کنم که ایجاد عکس های فوری و بازگرداندن سیستم فایل به آنها عملیات آنی هستند. ممکن است این سوال پیش بیاید: چگونه ممکن است که فوراً عملیاتی را با حجم منطقی که سه روز طول کشید به عقب برگردانید؟ اما ممکن است! به شرطی که فایل سیستم شما به درستی طراحی شده باشد. من سه سال پیش به ایده چنین "عکس های فوری سه بعدی" رسیدم و سال گذشته این تکنیک را به ثبت رساندم.
نکته بعدی که FS های محلی باید از شبکه ها بیاموزند این است که ابرداده ها را در دستگاه های جداگانه ذخیره کنند به همان روشی که FS های شبکه آنها را در ماشین های جداگانه (به اصطلاح سرورهای متادیتا) ذخیره می کنند. برنامههایی وجود دارند که عمدتاً با ابرداده کار میکنند، و این برنامهها را میتوان با قرار دادن ابرداده در دستگاههای ذخیرهسازی گران قیمت با کارایی بالا، تسریع کرد. با ترکیب FS+LVM، نمیتوانید چنین انتخابپذیری را نشان دهید: LVM نمیداند در بلوکی که به آن ارسال کردهاید (دادهها یا ابردادهها) چه چیزی وجود دارد.
شما از پیاده سازی LVM سطح پایین خود در FS در مقایسه با ترکیب FS+LVM سود زیادی نخواهید داشت، اما کاری که می توانید به خوبی انجام دهید این است که FS را بهم ریخته کنید تا بعداً کار با کد آن غیرممکن شود. ZFS و Btrfs که با دستگاههای مجازی هجوم آوردهاند، همه نمونههای واضحی هستند از اینکه چگونه نقض لایهبندی سیستم را از نظر معماری میکشد، پس چرا من این همه هستم؟ علاوه بر این، نیازی به نصب LVM سطح پایین خود در سیستم فایل نیست. در عوض، باید دستگاهها را در حجمهای منطقی در سطح بالایی جمع آوری کنید، همانطور که برخی از سیستمهای فایل شبکه با ماشینهای مختلف (گرههای ذخیرهسازی) انجام میدهند. درست است، آنها به دلیل استفاده از الگوریتم های بد این کار را به طرز زننده ای انجام می دهند.
نمونه هایی از الگوریتم های کاملاً وحشتناک مترجم DHT در سیستم فایل GlusterFS و به اصطلاح نقشه CRUSH در سیستم فایل Ceph هستند. هیچ کدام از الگوریتم هایی که دیدم از نظر سادگی و مقیاس پذیری خوب مرا راضی نکرد. بنابراین مجبور شدم جبر را به خاطر بسپارم و همه چیز را خودم اختراع کنم. در سال 2015، در حالی که باندلها را روی توابع هش آزمایش میکردم، به چیزی رسیدم و حق امتیازی را ثبت کردم که مناسب من است. اکنون می توانم بگویم که تلاش برای عملی کردن همه اینها موفقیت آمیز بود. من هیچ مشکلی در مقیاس پذیری در رویکرد جدید نمی بینم.
بله، هر زیر جلد به ساختار جداگانه ای مانند یک ابر بلوک در حافظه نیاز دارد. آیا این خیلی ترسناک است؟ به طور کلی، من نمی دانم چه کسی قرار است "اقیانوس" را بجوشاند و حجم های منطقی صدها هزار یا چند دستگاه را در یک ماشین محلی ایجاد کند. اگه کسی بتونه اینو برام توضیح بده خیلی ممنون میشم. در ضمن، برای من این یک مزخرف بازاریابی است.
چگونه تغییرات در زیر سیستم دستگاه بلوک هسته (به عنوان مثال، ظاهر blk-mq) بر الزامات اجرای FS تأثیر گذاشت؟
هیچ تاثیری نداشت من نمی دانم چه اتفاقی در لایه بلوک می افتد که طراحی یک FS جدید را ضروری می کند. رابط تعاملی این زیرسیستم ها بسیار ضعیف است. از سمت درایور، FS فقط باید تحت تأثیر ظاهر انواع جدیدی از درایوها باشد، که ابتدا لایه بلوک تنظیم می شود و سپس FS (برای reiser4 این به معنای ظاهر پلاگین های جدید است).
آیا ظهور انواع جدیدی از رسانه ها (مثلاً SMR یا فراگیر شدن SSD ها) اساساً به معنای چالش های جدیدی برای طراحی سیستم فایل است؟
آره. و اینها مشوق های عادی برای توسعه FS هستند. چالش ها می توانند متفاوت و کاملا غیرمنتظره باشند. به عنوان مثال، من در مورد درایوهایی شنیده ام که سرعت عملیات I/O به شدت به اندازه یک قطعه داده و افست آن بستگی دارد. در لینوکس، جایی که اندازه بلوک FS نمی تواند از اندازه صفحه بیشتر شود، چنین درایوی به طور پیش فرض قابلیت های کامل خود را نشان نمی دهد. با این حال، اگر سیستم فایل شما به درستی طراحی شده باشد، این شانس وجود دارد که از آن بهره بیشتری ببرید.
در حال حاضر چند نفر به جز شما با کد Reiser4 کار می کنند؟
کمتر از آنچه من می خواهم، اما من نیز با کمبود شدید منابع مواجه نیستم. من از سرعت توسعه Reiser4 راضی هستم. من قصد "اسب راندن" ندارم - این منطقه مناسب نیست. در اینجا، "اگر آرام تر رانندگی کنید، به راه خود ادامه خواهید داد!" یک سیستم فایل مدرن پیچیده ترین زیرسیستم هسته است که تصمیمات طراحی اشتباه آن می تواند سال های بعدی کار انسان را خنثی کند.
با ارائه داوطلبان برای اجرای چیزی، من همیشه تضمین می کنم که تلاش ها مطمئناً به نتیجه صحیح منجر می شود که می تواند برای نیازهای جدی تقاضا شود. همانطور که می دانید، نمی توان چنین ضمانت هایی را به طور همزمان وجود داشت. در عین حال، من نمیتوانم «شخصیتهایی» را تحمل کنم که بیشرمانه «ویژگیهای» نرمافزار آشکارا غیرقابل استفاده را تبلیغ میکنند، صدها کاربر و توسعهدهنده را فریب میدهند، و در عین حال در نشستهای هسته مینشینند و لبخند میزنند.
آیا هیچ شرکتی برای حمایت از توسعه Reiser4 ابراز تمایل کرده است؟
بله، چنین پیشنهادهایی وجود داشت، از جمله. و از یک فروشنده عمده اما برای این کار مجبور شدم به کشور دیگری نقل مکان کنم. متأسفانه، من دیگر 30 ساله نیستم، نمی توانم در همان سوت اول جدا شوم و آن را ترک کنم.
در حال حاضر چه ویژگی هایی در Reiser4 وجود ندارد؟
هیچ تابع "تغییر اندازه" برای حجم های ساده، مشابه آنچه در ReiserFS(v3) یافت می شود، وجود ندارد. علاوه بر این، عملیات فایل با پرچم DIRECT_IO ضرری ندارد. در مرحله بعد، من میخواهم بتوانم یک جلد را به «زیرجلدهای معنایی» که اندازه ثابتی ندارند و میتوانند به عنوان مجلدهای مستقل نصب شوند، تفکیک کنم. این مشکلات برای مبتدیانی که می خواهند دست خود را در "چیز واقعی" امتحان کنند خوب است.
و در نهایت، من می خواهم حجم های منطقی شبکه با پیاده سازی و مدیریت ساده داشته باشم (الگوریتم های مدرن قبلاً این اجازه را می دهند). اما چیزی که Reiser4 قطعا هرگز نخواهد داشت RAID-Z، اسکرابها، حافظههای پنهان فضای آزاد، متغیرهای 128 بیتی و سایر مزخرفات بازاریابی است که در پس زمینه کمبود ایدهها در میان توسعهدهندگان برخی از سیستمهای فایل به وجود آمد.
آیا هر چیزی که ممکن است مورد نیاز باشد توسط افزونه ها قابل پیاده سازی است؟
اگر فقط از نظر رابط ها و پلاگین ها (ماژول ها) که آنها را پیاده سازی می کنند صحبت کنیم، پس همه چیز نیست. اما اگر روابطی را روی این رابطها نیز معرفی کنید، در میان چیزهای دیگر، مفاهیم چندشکلی بالاتر را خواهید داشت که میتوانید از قبل با آنها کنار بیایید. تصور کنید که به طور فرضی یک سیستم زمان اجرا شی گرا را مسدود کرده اید، مقدار نشانگر دستورالعمل را تغییر داده اید تا به پلاگین دیگری اشاره کند که همان رابط X را پیاده سازی می کند، و سپس سیستم را از حالت انجماد خارج کنید تا به اجرا ادامه دهد.
اگر کاربر نهایی متوجه چنین "جایگزینی" نشود، می گوییم که سیستم دارای چندشکلی مرتبه صفر در رابط X است (یا سیستم در رابط X ناهمگن است، که همان چیزی است). اگر اکنون نه تنها مجموعه ای از رابط ها دارید، بلکه روابطی نیز روی آنها دارید (گراف رابط)، می توانید چندشکلی های مرتبه بالاتر را معرفی کنید که ناهمگونی سیستم را در "همسایگی" هر رابط مشخص می کند. من خیلی وقت پیش چنین طبقه بندی را معرفی کردم، اما، متأسفانه، هرگز اتفاق نیفتاد.
بنابراین، با کمک پلاگین ها و چنین پلی مورفیسم های بالاتر، می توانید هر ویژگی شناخته شده ای را توصیف کنید، و همچنین مواردی را که هرگز ذکر نشده اند را "پیش بینی" کنید. من نتوانستم این را به طور دقیق ثابت کنم، اما هنوز مثال متقابلی هم نمیدانم. به طور کلی، این سوال من را به یاد "برنامه ارلانگن" فلیکس کلاین انداخت. در یک زمان او سعی کرد تمام هندسه را به عنوان شاخه ای از جبر (به طور خاص، نظریه گروه) نشان دهد.
حال به سوال اصلی - با ارتقای Reiser4 به هسته اصلی، کارها چگونه پیش می رود؟ آیا انتشاراتی در مورد معماری این فایل سیستم وجود داشت که در مصاحبه قبلی در مورد آن صحبت کردید؟ این سوال از دیدگاه شما چقدر مرتبط است؟
در کل سه سال است که تقاضای ورود به شعبه اصلی را داریم. آخرین نظر ریزر در تاپیک عمومی که در آن درخواست کشش صورت گرفته بود، بی پاسخ ماند. بنابراین تمام سوالات بعدی برای ما نیست. من شخصاً نمی فهمم که چرا باید در یک سیستم عامل خاص "ادغام" شویم. در لینوکس، نور مانند یک گوه همگرا نمی شد. بنابراین، یک مخزن جداگانه وجود دارد که در آن چندین شعبه پورت برای سیستم عامل های مختلف وجود خواهد داشت. هر کس به آن نیاز دارد می تواند پورت مربوطه را کلون کند و هر کاری که می خواهید با آن انجام دهد (البته در لایسنس). خوب، اگر کسی به آن نیاز ندارد، پس مشکل من نیست. در این مرحله، من پیشنهاد میکنم که مسئله «ترفیع به هسته اصلی لینوکس» حل شده باشد.
انتشارات مربوط به معماری FS مرتبط هستند، اما تا کنون فقط برای نتایج جدیدم زمان پیدا کرده ام که آن را اولویت بالاتری می دانم. نکته دیگر این است که من ریاضیدان هستم و در ریاضیات هر چاپی خلاصه ای از قضایا و برهان آنهاست. انتشار هر چیزی در آنجا بدون مدرک نشانه بد سلیقه است. اگر من به طور کامل هر جمله ای را در مورد معماری FS اثبات یا رد کنم، نتیجه آن چنان انبوه خواهد بود که عبور از آن بسیار دشوار خواهد بود. چه کسی به آن نیاز دارد؟ احتمالاً به همین دلیل است که همه چیز به شکل قدیمی خود - کد منبع و نظرات مربوط به آن - باقی می ماند.
در چند سال گذشته در Reiser4 چه چیز جدیدی وجود دارد؟
ثباتی که مدت ها انتظارش را می کشید بالاخره محقق شد. یکی از آخرین مواردی که ظاهر شد، باگی بود که منجر به دایرکتوری های "غیرقابل حذف" شد. مشکل این بود که فقط در پس زمینه برخورد هش نام و با مکان خاصی از رکوردهای دایرکتوری در یک گره درختی ظاهر می شد. با این حال، من هنوز نمیتوانم Reiser4 را برای تولید توصیه کنم: برای این کار باید با تعامل فعال با مدیران سیستم تولید کار کنید.
ما در نهایت موفق شدیم ایده دیرینه خود را - مدل های مختلف تراکنش - پیاده سازی کنیم. پیش از این، Reiser4 تنها یک مدل Macdonald-Reiser کد سخت را اجرا می کرد. این باعث ایجاد مشکلاتی در طراحی شد. به طور خاص، عکس های فوری در چنین مدل تراکنشی امکان پذیر نیست - آنها توسط یک جزء اتمی به نام "OVERWRITE SET" خراب می شوند. Reiser4 در حال حاضر از سه مدل تراکنش پشتیبانی می کند. در یکی از آنها (Write-Anywhere)، مولفه اتمی OVERWRITE SET فقط شامل صفحات سیستم (تصاویر بیت مپ دیسک و غیره) است که نمی توان آنها را "عکاسی" کرد (مشکل مرغ و تخم مرغ).
بنابراین اکنون می توان تصاویر را به بهترین شکل ممکن اجرا کرد. در یک مدل تراکنشی دیگر، تمام صفحات اصلاح شده فقط به مجموعه OVERWRITE می روند (یعنی اساساً ژورنالینگ خالص است). این مدل برای کسانی است که از تکه تکه شدن سریع پارتیشن های Reiser4 شکایت دارند. اکنون در این مدل پارتیشن شما سریعتر از ReiserFS (v3) تکه تکه می شود. هر سه مدل موجود با کمی ملاحظات، اتمی بودن عملیات را تضمین میکنند، اما مدلهایی با کاهش اتمی و حفظ یکپارچگی بخش نیز میتوانند مفید باشند. چنین مدل هایی می توانند برای انواع برنامه ها (پایگاه های داده و غیره) که قبلاً برخی از این عملکردها را بر عهده گرفته اند مفید باشند. اضافه کردن این مدل ها به Reiser4 بسیار آسان است، اما من این کار را نکردم، زیرا کسی از من نپرسید و من شخصاً به آن نیازی ندارم.
جمعهای کنترلی فراداده ظاهر شدند و من اخیراً آنها را با آینههای "اقتصادی" تکمیل کردم (مواد هنوز ناپایدار). اگر جمع چک هر بلوکی از کار بیفتد، Reiser4 بلافاصله بلوک مربوطه را از دستگاه replica می خواند. توجه داشته باشید که ZFS و Btrfs نمی توانند این کار را انجام دهند: طراحی اجازه نمی دهد. در آنجا باید یک فرآیند اسکن پسزمینه خاص به نام «scrub» را اجرا کنید و منتظر بمانید تا به بلوک مشکلساز برسد. برنامه نویسان به طور مجازی به چنین رویدادهایی "عصا" می گویند.
و در نهایت، حجمهای منطقی ناهمگن ظاهر شدهاند، و همه چیزهایی را ارائه میدهند که ZFS، Btrfs، لایه بلوک، و همچنین ترکیبهای FS+LVM در اصل نمیتوانند ارائه کنند - مقیاسبندی موازی، تخصیصدهنده آدرس دیسک O(1)، انتقال داده شفاف بین زیرجلدها. دومی یک رابط کاربری نیز دارد. اکنون می توانید به راحتی داغ ترین داده ها را به درایو با بالاترین عملکرد در حجم خود منتقل کنید.
علاوه بر این، میتوان فوراً هر صفحه کثیفی را روی چنین درایوی پاک کرد و در نتیجه سرعت برنامههایی را که اغلب fsync(2) مینامند افزایش میدهد. توجه داشته باشم که عملکرد لایه بلوک، به نام bcache، به هیچ وجه چنین آزادی عمل را ارائه نمی دهد. حجم های منطقی جدید بر اساس الگوریتم های من هستند (پتنت های مربوطه وجود دارد). نرم افزار در حال حاضر کاملاً پایدار است، آزمایش آن، اندازه گیری عملکرد و غیره کاملاً امکان پذیر است. تنها ناراحتی این است که در حال حاضر باید پیکربندی صدا را به صورت دستی به روز کنید و آن را در جایی ذخیره کنید.
تاکنون توانستهام ایدههایم را تا 10 درصد پیادهسازی کنم، با این حال، در چیزی که سختترین چیز را در نظر میگرفتم موفق شدم - اتصال حجمهای منطقی با یک رویه فلش که همه اقدامات معوق را در reiser4 انجام میدهد. این همه هنوز در شاخه آزمایشی "format41" است.
آیا Reiser4 xfstests را پاس می کند؟
حداقل زمانی که داشتم آخرین نسخه را آماده میکردم این کار را برای من انجام داد.
آیا اصولاً می توان Reiser4 را با استفاده از افزونه ها به FS شبکه (خوشه ای) تبدیل کرد؟
ممکن است و حتی ضروری! اگر یک فایل شبکه بر اساس یک سیستم فایل محلی به درستی طراحی شده ایجاد کنید، نتیجه بسیار چشمگیر خواهد بود! در FS های شبکه مدرن، من از وجود سطح ذخیره سازی Backend که با استفاده از هر FS محلی پیاده سازی می شود، راضی نیستم. وجود این سطح کاملا غیر قابل توجیه است. شبکه FS باید مستقیماً با لایه بلوک تعامل داشته باشد و از FS محلی بخواهد هیچ فایل سرویس دیگری ایجاد کند!
به طور کلی، تقسیم سیستم های فایل به محلی و شبکه ای از شیطان است. این از نقص الگوریتمهایی ناشی میشود که سی سال پیش مورد استفاده قرار میگرفتند و هنوز چیزی به جای آنها پیشنهاد نشده بود. این نیز دلیل ظاهر شدن انبوهی از اجزای نرم افزاری غیر ضروری (سرویس های مختلف و غیره) است. به روشی خوب، باید فقط یک FS به شکل یک ماژول هسته و مجموعه ای از ابزارهای کاربری نصب شده روی هر ماشین وجود داشته باشد - یک گره خوشه. این FS هم محلی و هم شبکه است. و نه چیزی بیشتر!
اگر با Reiser4 در Linuxاگر هیچ اتفاقی نیفتد، دوست دارم یک FS برای FreeBSD پیشنهاد بدهم (نقل قول از مصاحبه قبلی: «...FreeBSD... ریشههای آکادمیک دارد... و این یعنی با احتمال بالا، ما با توسعهدهندگان به یک زبان مشترک خواهیم رسید»).
بنابراین، همانطور که ما به تازگی متوجه شدیم، همه چیز قبلاً با لینوکس به خوبی انجام شده است: یک پورت Reiser4 کار جداگانه برای آن در قالب یک شاخه اصلی مخزن ما وجود دارد. FreeBSD را فراموش نکرده ام! پیشنهاد! من آماده همکاری نزدیک با کسانی هستم که درونیات FreeBSD را به خوبی می شناسند. اتفاقاً: چیزی که من واقعاً در مورد جامعه آنها دوست دارم این است که تصمیمات در آنجا توسط یک شورای به روز شده از کارشناسان مستقل گرفته می شود که ربطی به فریب دولتی یک فرد دائمی ندارد.
جامعه کاربری را چگونه ارزیابی میکنید؟ Linux امروز؟ آیا بیشتر «عامیانه» شده است؟
با توجه به ماهیت کارم، ارزیابی این موضوع برایم بسیار دشوار است. بیشتر کاربران با گزارش های اشکال و درخواست هایی برای رفع این بخش به من مراجعه می کنند. کاربران به عنوان کاربران برخی باهوش ترند، برخی کمتر. با همه یکسان رفتار می شود. خوب، اگر کاربر دستورالعمل های من را نادیده گرفت، ببخشید: دستور نادیده گرفتن از طرف من نیز وارد می شود.
آیا می توان توسعه سیستم های فایل را برای پنج تا ده سال آینده پیش بینی کرد؟ به نظر شما چالش های اصلی که توسعه دهندگان FS ممکن است با آن مواجه شوند چیست؟
بله، انجام چنین پیش بینی سختی نیست. برای مدت طولانی هیچ سیستم فایلی در بالادست توسعه نیافته است. فقط ظاهر چنین ایجاد می شود. توسعه دهندگان سیستم های فایل محلی با مشکلات مرتبط با طراحی ضعیف مواجه شدند. در اینجا باید یک اخطار انجام شود. من به اصطلاح "ذخیره سازی"، "لیسیدن" و انتقال کد را توسعه و توسعه نمی دانم. و من سوء تفاهم به نام "Btrfs" را به دلایلی که قبلاً توضیح دادم به عنوان توسعه طبقه بندی نمی کنم.
هر پچ فقط مشکلات خود را بدتر می کند. خوب. و همیشه انواع مختلفی از «مبلغان» وجود دارند که «همه چیز برای آنها کار میکند». اساساً اینها دانش آموزان و دانش آموزانی هستند که از سخنرانی خودداری می کنند. فقط تصور کنید: برای او کار می کند، اما استاد اینطور نیست. این چه هجوم آدرنالین است! از دیدگاه من، بیشترین آسیب را «صاحبانی» وارد میکنند که با اشتیاق هجوم آوردند تا ویژگیهای شگفتانگیز Btrfs را به انواع لایهها مانند systemd، docker و غیره «پیچ» کنند. - این قبلاً شبیه متاستاز است.
حالا بیایید سعی کنیم برای پنج تا ده سال پیش بینی کنیم. من قبلاً به طور خلاصه لیست کرده ام که در Reiser4 چه خواهیم کرد. چالش اصلی برای توسعه دهندگان محلی FS از بالادست (بله، قبلاً تبدیل شده است) ناتوانی در انجام یک کار مناسب با حقوق خواهد بود. بدون هیچ ایده ای در زمینه ذخیره سازی داده ها، آنها به تلاش خود برای وصله این VFS، XFS و ext4 ناگوار ادامه خواهند داد. وضعیت VFS در این زمینه به ویژه خنده دار به نظر می رسد، یادآور مدرنیزاسیون دیوانه کننده رستورانی است که در آن نه سرآشپزی وجود دارد و نه سرآشپزی انتظار می رود.
اکنون، کد VFS بدون قید و شرط چندین صفحه حافظه را به طور همزمان قفل میکند و از سیستم فایل اصلی درخواست میکند که روی آنها عمل کند. این قابلیت برای بهبود عملکرد Ext4 در حین عملیات حذف معرفی شده است، اما همانطور که به راحتی میتوانید متوجه شوید، چنین قفل همزمانی کاملاً با مدلهای تراکنشی پیشرفته ناسازگار است. این بدان معناست که شما نمیتوانید به سادگی پشتیبانی از نوعی سیستم فایل هوشمند را به هسته اضافه کنید. من نمیدانم اوضاع در زمینههای دیگر چگونه است. Linuxاما وقتی صحبت از سیستمهای فایل میشود، هرگونه توسعهای در اینجا به سختی با سیاستهایی که توروالدز در واقع دنبال میکند، سازگار است (پروژههای دانشگاهی حذف میشوند و به کلاهبردارانی که هیچ ایدهای از چیستی درخت B ندارند، اعتبار بیپایانی داده میشود). بنابراین، یک دوره زوال تدریجی آغاز شده است. البته، آنها تمام تلاش خود را خواهند کرد تا این را به عنوان «توسعه» جا بزنند.
علاوه بر این، "متولیان" سیستم های فایل، با درک این که شما به تنهایی از "ذخیره سازی" درآمد زیادی نخواهید داشت، دست خود را در یک تجارت سودآورتر امتحان می کنند. اینها معمولاً سیستم های فایل توزیع شده و مجازی سازی هستند. شاید آنها ZFS مد روز را به جای دیگری منتقل کنند که هنوز وجود ندارد. اما مانند تمام FS های بالادست، شبیه درخت سال نو است: اگر بتوانید چیزهای کوچک دیگری را در بالا آویزان کنید، دیگر نمی توانید عمیق تر شوید. اعتراف می کنم که می توان یک سیستم سازمانی جدی مبتنی بر ZFS ساخت، اما از آنجایی که ما اکنون در حال بحث در مورد آینده هستیم، فقط می توانم بگویم که ZFS در این زمینه ناامید است: بچه ها با دستگاه های مجازی خود اکسیژن را قطع کرده اند. برای خود و نسل های آینده برای توسعه بیشتر. ZFS متعلق به گذشته است. و ext4 و XFS حتی دیروز هم نیستند.
شایان ذکر است که به طور جداگانه به مفهوم بسیار مورد بحث "" اشاره کنیم.Linux سیستم فایل نسل بعدی." این یک پروژه کاملاً سیاسی و بازاریابی است که ایجاد شده تا بتواند، به اصطلاح، "آینده سیستمهای فایل را در دست بگیرد". Linux برای شخصیتهای خاص. مسئله این است که قبلاً اینطور بود Linux قبلاً «فقط برای سرگرمی» بود. حالا، در درجه اول یک ماشین پولسازی است. پول از هر چیزی و هر کاری به دست میآید. برای مثال، ساخت یک محصول نرمافزاری خوب بسیار دشوار است، اما «توسعهدهندگان» باهوش مدتهاست که متوجه شدهاند که اصلاً نیازی به تلاش نیست: حتی نرمافزارهای ناموجود، که در انواع رویدادهای عمومی معرفی و تبلیغ میشوند، میتوانند با موفقیت فروخته شوند - نکته اصلی این است که ویژگیهای زیادی در اسلایدهای ارائه وجود داشته باشد.
سیستم های فایل برای این کار عالی هستند، زیرا می توانید ده سال با خیال راحت روی نتیجه چانه بزنید. خوب، اگر بعداً کسی از فقدان این نتیجه شکایت کند، پس او به سادگی چیزی در مورد سیستم های فایل نمی فهمد! این یادآور یک هرم مالی است: در راس آن ماجراجوانی هستند که این آشفتگی را به راه انداختند، و آن عده معدودی که "خوش شانس" بودند: آنها "سود سهام را برداشتند"، یعنی. برای توسعه پول دریافت کرد، شغلی با درآمد خوب به عنوان مدیر دریافت کرد، در کنفرانس ها ظاهر شد و غیره.
بعداً کسانی می آیند که "بدشانس" هستند: آنها ضرر می شمارند، با عواقب استقرار یک محصول نرم افزاری غیرقابل استفاده در تولید مقابله می کنند، "و غیره. تعداد بیشتری از آنها وجود دارد. خوب، در پایه هرم توده عظیمی از توسعه دهندگان وجود دارد که کدهای بی فایده را "اره" می کنند. آنها بزرگترین بازندگان هستند، زیرا زمان تلف شده قابل بازگشت نیست. چنین اهرامی برای توروالدز و همکارانش بسیار مفید است. و هر چه تعداد این اهرام بیشتر باشد برای آنها بهتر است. برای تغذیه چنین اهرامی، هر چیزی را می توان در هسته گرفت. البته در ملاء عام برعکس می گویند. اما من نه با گفتار بلکه با اعمال قضاوت می کنم.
بنابراین، «آینده سیستمهای فایل لینوکس» هنوز یک نرمافزار بسیار پر سر و صدا اما با کاربرد ضعیف است. پس از Btrfs، بسیار محتمل است که این «آینده» با Bcachefs جایگزین شود، که تلاش دیگری برای پیوند زدن است. Linux یک لایه بلوکی با یک سیستم فایل (مثال بد مسری است). و نکته جالب این است که همان مشکلات Btrfs را دارد. من مدتها به این موضوع مشکوک بودم، و بعد نتوانستم در مقابل نگاه کردن به کد مقاومت کنم - و این درست است!
نویسندگان Bcachefs و Btrfs، هنگام ایجاد FS خود، به طور فعال از منابع دیگران استفاده می کردند و درک کمی از آنها داشتند. این وضعیت بسیار یادآور بازی کودکانه "تلفن خراب" است. و من تقریباً می توانم تصور کنم که چگونه این کد در هسته گنجانده می شود. در واقع، هیچ کس "راک ها" را نخواهد دید (همه بعداً روی آنها قدم خواهند گذاشت). پس از ایرادهای متعدد در مورد سبک کد، اتهامات عدم وجود نقض و غیره، نتیجه گیری در مورد "وفاداری" نویسنده، چگونگی "تعامل" او با دیگر توسعه دهندگان، و موفقیت آمیز بودن همه اینها انجام خواهد شد. سپس به شرکت ها فروخته شود.
نتیجه نهایی برای کسی جالب نخواهد بود. شاید بیست سال پیش علاقه مند بودم، اما اکنون سؤالات به گونه ای دیگر مطرح می شود: آیا امکان ارتقای این امر به گونه ای وجود دارد که افراد خاصی ظرف ده سال آینده استخدام شوند؟ و افسوس که متعارف نیست که در مورد نتیجه نهایی تعجب کنیم.
به طور کلی، من اکیداً توصیه می کنم که سیستم فایل خود را از ابتدا اختراع مجدد نکنید. زیرا حتی سرمایه گذاری های مالی قابل توجه نیز برای بدست آوردن چیزی رقابتی در ده سال کافی نخواهد بود. البته، من در مورد پروژههای جدی صحبت میکنم، و نه در مورد پروژههایی که قرار است به درون هسته «هل» شوند. بنابراین، یک راه مؤثرتر برای بیان خود، پیوستن به تحولات واقعی است، مانند ما. البته انجام این کار آسان نیست - اما این در مورد هر پروژه سطح بالا صدق می کند.
اول، شما باید به طور مستقل بر مشکلی که من ارائه می دهم غلبه کنید. پس از آن، با اطمینان از جدی بودن نیات شما، شروع به کمک خواهم کرد. به طور سنتی، ما فقط از پیشرفت های خود استفاده می کنیم. استثناها الگوریتم های فشرده سازی و برخی از توابع هش هستند. ما توسعهدهندگان را برای سفر به کنفرانسها نمیفرستیم، و سپس نمینشینیم و ایدههای دیگران را ترکیب نمیکنیم («شاید چه اتفاقی بیفتد»)، همانطور که در اکثر استارتآپها مرسوم است.
ما خودمان همه الگوریتمها را توسعه میدهیم. در حال حاضر، من به جنبههای جبری و ترکیبی علم ذخیرهسازی دادهها علاقهمند هستم. به طور خاص، میدانهای متناهی، مجانبها و نابرابریها. برای برنامهنویسان معمولی هم کار وجود دارد، اما باید فوراً به شما هشدار دهم: تمام پیشنهادها مبنی بر «به سیستم فایل دیگری نگاه کنید و همین کار را انجام دهید» نادیده گرفته خواهند شد. وصلههایی با هدف ادغام نزدیکتر با Linux از طریق خط VFS.
بنابراین، ما چنگک جمعآوری نداریم، اما میدانیم که کجا باید حرکت کنیم، و اطمینان داریم که این مسیر درست است. این درک به صورت مانا از بهشت نیامد. اجازه دهید به شما یادآوری کنم که ما 29 سال تجربه توسعه در پشت خود داریم، دو سیستم فایل که از ابتدا نوشته شده اند. و همین تعداد ابزار بازیابی اطلاعات. و این خیلی است!
منبع: opennet.ru
