۱- فقط از subvolume ریشه snapshot گرفته میشه.
۲- تا جایی که یادمه باید کامپیوتر رو راه‌اندازی مجدد کنید و توی خط فرمان کرنل، پارامتر root رو به subvolume درست تغییر بدید.
برای آرچ لینوکس بسته grub-btrfs هست که snapshot ها رو به منوی گراب اضافه میکنه.
snapper هم هست که کار مربوط به snapshot گیری خودکار رو انجام بده.
توی آرچ لینوکس بسته snap-pac هم هست که قبل از هر بروزرسانی با pacman، یه snapshot از روت ایجاد میکنه.
snap-pac-grub توی aur وجود داره که بعد از اینکه snap-pac کار رو انجام داد، منوی گراب رو آپدیت کنه. به هر دو بسته snap-pac و grub-btrfs وابسته هست.
توی دبیان هم چیز‌هایی شبیه اینها بود، اسمشون رو یادم نیست.
۳- به نظر میاد درست نمی‌دونید که luks چجوری کار میکنه.
luks یه کلید لازم داره تا اطلاعات رو باهاش رمزنگاری کنه. وقتی که یه جایی رو به luks فرمت می‌کنید، یه کلید اصلی به طور تصادفی ساخته میشه که همه اطلاعات با اون رمزنگاری و رمزگشایی میشن. این کلید تغییر نمی‌کنه، مگه اینکه از luks بخواهید یه کلید اصلی دیگه بسازه و اطلاعات رو دوباره با اون کلید جدید رمزنگاری کنه.
این کلید اصلی مستقیم در اختیار کاربر قرار نمی‌گیره. وقتی که برای luks یه کلید (مثلا رمز عبور یا یه key file) تعیین می‌کنید، اون کلید به عنوان کلید اصلی استفاده نمیشه.
نحوه کار اینجوریه که کلید اصلی، توسط کلیدی که وارد می‌کنید رمزنگاری، و روی header های luks ذخیره میشه.
وقتی کلید رو میدید، اول کلید اصلی با استفاده از کلیدی که دادید رمزگشایی میشه و بعد با اون کلید اصلی، اطلاعات واقعی رمزنگاری و رمزگشایی میشن.
خوبی این روش اینه که می‌تونید چندین کلید داشته باشید. برای هر کلیدی که شما می‌سازید، اون کلید اصلی با همون کلید موردنظر، رمزنگاری میشه و روی header های luks قرار می‌گیره. تا جایی که یادمه luks2 می‌تونه حداکثر ۸ تا کلید متفاوت داشته باشه. مطمئن نیستم.
اون کلیدی که شما انتخاب می‌کنید می‌تونه یه رمز عبور باشه. البته قبل از اینکه مستقیم استفاده بشه، طی یه سری مراحلی پیچیدگی اون افزایش پیدا میکنه تا نشه راحت بدستش آورد.
کلید ممکنه یه فایل هم باشه. در این حالت، کلید اصلی با استفاده از یه فایل رمزنگاری میشه و اگه اون فایل رو داشته باشید، می‌تونید جایی که رمزنگاری شده هست رو باز کنید.
با توجه به اینها، شما یا رمز دارید یا key file. وقتی هم یه توزیع دیگه نصب می‌کنید، باید حداقل یکی از این ۸ تا کلید رو داشته باشید تا بتونید جایی که رمزنگاری شده هست رو باز و اون subvolume های فایل‌سیستم btrfs رو سوار کنید.
به غیر از چیز‌های بالا، چرا /usr/ یا /lib/ یا خیلی چیز‌های دیگه مثل /bin/ یا /sbin رو جدا کردید و هر کدوم رو گذاشتید روی یه subvume مجزا؟
مدتیه توی اکثر توزیع‌ها، دایرکتوری‌های /lib/ /sbin/ /bin/ /lib64/ /lib32/ /libx32/ یه لینک به دایرکتوری متناظر توی /usr/ هستند. مثلا /lib/ یه لینک به usr/lib هست.
پس به همین دلیل لازم نیست /sbin/ /bin/ و /lib/ رو جدا کنید. فکر کنم اصلا نباید در این حالت اونها رو جدا کنید.
روی /dev/ هم یه فایل‌سیستم‌مجازی devtmpfs سوار میشه و لازم نیست جداش کنید. از اونجایی که /dev/ توی مراحل اولیه بوت، توسط initramfs سوار میشه، فکر کنم تخصیص دادن یه subvolume به /dev/ باعث مشکل میشه.
به این دلیل که اون subvolume توی مراحل پایانی بوت سوار میشه و با این سوار شدن، محتوای قبلی /dev/ پوشیده میشه و اونها غیر قابل دسترس میشن. وقتی هم این اتفاق بیوفته، خیلی از برنامه‌ها نمی‌تونند کار کنند..
/media/ هم لازم نیست جدا باشه. بعضی ابزار‌ها مثل udisk چیز‌ها رو روی یه سری زیردایر‌کتوری توی /media/ سوار می‌کنند. در اصل /media/ یه جایی هست تا سوار کردن‌های موقت روی اون انجام بشه.
اینکه /tmp/ رو جدا کنید، مشکلی نداره. بعضی جاها هم پیشنهاد میشه که /tmp/ رو جدا کنید تا بتونید برای اون quota در نظر بگیرید تا یه کسی نتونه اون رو کامل پر کنه و برای سیستم مشکل ایجاد کنه.
/etc/ رو چرا جدا کردید؟ /etc/ رو هم بذارید جز / باقی بمونه.
/usr/ رو هم لازم نیست جدا کنید. توی اکثر توزیع‌ها، تقریبا همه چیز‌های سیستم‌عامل داخل /usr/ قرار داره (به غیر از خود کرنل و پیکربندی‌های داخل /etc/) این چیز‌هایی که داخل /usr/ قرار دارند، باید با چیز‌های داخل /etc/ هماهنگ باشند.
اینکه هر کدوم توی subvolume جدا باشند باعث میشه موقعی که یه snapshot از روت گرفتید و بعد وضعیت رو به اون snapshot برگردوندید، چیز‌های داخل /usr/ و /etc/ با هم هماهنگ نباشند و مشکل ایجاد بشه.
یه راه حل اینه که یه سازوکاری ایجاد کنید که این snapshotها رو به درستی مدیریت کنه. خود این سازوکار باعث افزایش پیچیدگی میشه. گزینه بهتر اینه که اصلا /usr/ رو از / جدا نکنید تا به این سازوکار هم نیاز نشه.
به همون دلایل بالا، /var/ رو هم جدا نکنید. مدیربسته معمولا یه پایگاه داده از بسته‌ها، فایل‌هاشون و وضعیت اونها داخل /var/lib/ نگهداری میکنه. اینکه پایگاه داده مدیربسته با وضعیت فعلی سیستم هماهنگ نباشه، می‌تونه به شدت مشکل درست کنه.
اگه دایرکتوری‌های مجزا توی /var/lib/ رو بر اساس نیاز جدا کنید، بهتره. مثلا من خودم /var/lib/libvirt/ و /var/lib/docker/ که به ترتیب مربوط به libvirt و docker هستند رو جدا کردم تا اطلاعات مربوط به اونها موقع برگردوندن یه snapshot از روت، به حالت قبل برنگرده.
/boot/ رو هم معمولا لازم نیست جدا کنید. دلیل خاصی برای اینکار دارید؟ اگه دلیل خاصی ندارید، بهتره بذارید جز همون / باقی بمونه.
/opt/ معمولا برای برنامه‌هایی استفاده میشه که از خارج از مخازن نصب شدند. شاید بخواهید /opt/ جزیی از / باشه، شاید هم بخواهید جدا باشه. بستگی به شرایط خودتون انتخاب کنید. اگه من باشم، /opt/ رو از / جدا نمی‌کنم.
گزارش‌های (لاگ‌ها) سرویس‌ها، کرنل و اینجور چیز‌ها معمولا توی /var/log/ ذخیره میشه. بهتره که /var/log/ رو اگه می‌خواهید جدا کنید. اینجوری نوقع برگردوندن یه snapshot، گزارش‌های جدید از دست نمیرن.
/var/tmp/ هم که مثل /tmp/ می‌مونه هم میشه جدا کرد تا بتونید برای اون quota تعیین کنید.
اگه هوم روت (root) رو هم جدا کنید بد نیست. انتخابش با خودتون هست.
می‌تونید از یه tmpfs برای /var/tmp/ و /tmp/ استفاده کنید تا سرعت خوندن و نوشتن فایل‌های موقتی بیشتر بشه، به قیمت اینکه اون فایل‌های موقتی روی رم ذخیره بشن و رم رو اشغال کنند. (اگه رم کمی دارید، گزینه مناسبی نیست)
با توجه به این چیز‌ها، این subvolume ها حتما رو بسازید.
@ mountpoint=/
@home mountpoint=/home
@snapshots mountpoint=/.snapshotssubvolume با اسم @ برای روت استفاده میشه به طوری که /usr/ و /boot/ و /var/ جزیی از اون باقی می‌مونند.
subvolume با اسم home@ هم برای /home/ استفاده میشه. می‌تونید برای هوم هر کاربر هم subvolume جدا بسازید.
لازم نیست اسم subvolume ها حتما با علامت @ شروع بشه. هر چیزی می‌تونه باشه. (البته به غیر از کاراکتر NULL و /)
مثلا می‌تونید اسم subvolume روت رو بذارید rootfs یا هر چی که می‌خواهید، فقط یه اسمه که باید همه جا از اون استفاده کنید.
برای subvolume هوم هم همینطور؛ مثلا اسمش رو بذارید homedir به جای home@.
اگه من باشم، این subvolume ها رو هم میسازم:
@tmp mountpoint=/tmp
@home-root mountpoint=/root
@var-tmp mountpoint=/var/tmp
@var-log mountpoint=/var/logاگه می‌خواهید همزمان چنتا توزیع نصب کنید، بهتره هر کدوم یه subvolume جدا برای /var/log/ داشته باشند تا گزارش‌های اونها با هم به تداخل نخوره.
مثلا debian-var-log@ برای دبیان و manjaro-var-log@ برای مانجارو.
چیز‌های دیگه‌ای هم هستند که قابلیت‌هایی شبیه btrfs دارند. برای مثال lvm، ولی قابلیت‌هاش کمی کمتر از btrfs هست. هرچند به دلیل اینکه مدت زیادی استفاده شده، پایداری خیلی خوبی داره.
فایل‌سیستم bcachefs هم هست ولی هنوز قابلیت‌های مهم اون پایدار نشده و ماژول‌های مربوط بهش هم همراه کرنل نیست. باید خودتون جدا ماژول‌هاش رو از کد منبع کامپایل کنید.
فایل‌سیستم zfs هم هست که از نظر من از همه گزینه‌ها بهتره. قابلیت‌های بیشتری نسبت به btrfs داره و اکثر ویژگی‌های اون هم پایداره.
خود فایل‌سیستم به صورت داخلی از رمزنگاری پشتیبانی میکنه، بدون نیاز به luks؛ البته یه قابلیت مربوط به این رمزنگاری مشکل داره. ولی این مشکل فقط توی بعضی شرایط خاص روی میده.
مشکل دیگه اون اینه که که با مجوز cddl منتشر میشه. این مجوز با مجوز gpl2 که اکثر کد کرنل لینوکس تحت این مجوز منتشر میشه ناسازگاره و به خاطر همین zfs همراه کرنل لینوکس نیست و باید جدا کامپایل بشه.
اما توی اکثر توزیع‌ها در قالب یه بسته موجوده که dkms اون رو کامپایل نصب و مدیریت کنه. به همین دلیل نصبش کار سختی نیست. اوبونتو اون رو به صورت کامپایل شده همراه کرنلش قرار داده.
مورد بعدی اینه که بیشتر توسعه پروژه zfs on linux توسط سازمان llnl، زیرمجموعه‌ای از وزارت انرژی آمریکا انجام میشه. اکثر تحقیقات این وزارت در حوزه فیزیک هسته‌ای و جنگ‌افزار‌های هسته‌ای هست. (فردا از گونی سردر میارم
)
موضوع: سوالاتی درباره btrfs (دفعات بازدید: 1198 بار)
