نام (NAME)

storage.conf - پرونده پیکربندی برای مدیر ذخیره‌سازی

توضیحات (DESCRIPTION)

پرونده pathetc/storage.conf شامل قوانینی است که برای تخصیص مقاله‌ها به روش‌های مختلف ذخیره‌سازی استفاده می‌شوند. این قوانین تعیین می‌کنند که مقاله‌های ورودی در کجا ذخیره شوند.

مدیر ذخیره‌سازی یک واسط یکپارچه میان INN و انواع روش‌های مختلف ذخیره‌سازی است که به مدیر اخبار امکان می‌دهد بین روش‌های گوناگون ذخیره‌سازی با موازنه‌ها و مزایا و معایب مختلف انتخاب کند (یا حتی از چندین روش به‌طور همزمان برای گروه‌های خبری مختلف یا مقاله‌هایی با اندازه‌های متفاوت استفاده نماید). سایر بخش‌های INN نیازی ندارند بدانند برای یک مقاله مشخص از چه نوع روش ذخیره‌سازی استفاده شده است؛ مدیر ذخیره‌سازی هنگام بازیابی آن مقاله از طریق API ذخیره‌سازی، این موضوع را به‌طور خودکار تشخیص خواهد داد. توجه داشته باشید که ممکن است بخواهید گزینه‌های ارائه‌شده در inn.conf(5) را نیز درباره ذخیره‌سازی مقاله‌ها بررسی کنید.

پرونده storage.conf از مجموعه‌ای از مدخل‌های روش‌های ذخیره‌سازی تشکیل شده است. خطوط خالی و خطوطی که با علامت هش ("#") آغاز می‌شوند نادیده گرفته خواهند شد. حداکثر تعداد نویسه‌ها در هر خط ۲۵۵ است. ترتیب مدخل‌ها در این پرونده اهمیت دارد؛ توضیحات زیر را ببینید.

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

method <methodname> {
    newsgroups: <wildmat>
    class: <storage_class>
    size: <minsize>[,<maxsize>]
    expires: <mintime>[,<maxtime>]
    options: <options>
    exactmatch: <bool>
    filtered: <bool>
    path: <wildmat>
}

اگر فاصله یا تب در یک مقدار گنجانده شده باشد، آن مقدار باید درون علامت‌های نقل‌قول دوتایی ("") محصور شود. اگر بخواهید علامت هش ("#") یا نقل‌قول دوتایی را دقیقاً به صورت تحت‌اللفظی در یک مقدار درج کنید، باید با "\" اسکیپ شوند.

مقدار <methodname> نام روش ذخیره‌سازی است که باید برای مقاله‌های منطبق با قوانین این مدخل استفاده شود. روش‌های ذخیره‌سازی که در حال حاضر در دسترس هستند عبارتند از:

cnfs
timecaf
timehash
tradspool
trash

برای جزئیات بیشتر بخش «روش‌های ذخیره‌سازی (STORAGE METHODS)» را در ادامه ببینید.

معانی کلیدها در هر مدخل روش ذخیره‌سازی به شرح زیر است:

newsgroups: <wildmat>

مشخص می‌کند چه گروه‌های خبری با این روش ذخیره‌سازی نگهداری شوند. مقدار <wildmat> یک الگوی uwildmat است که با گروه‌های خبری که مقاله به آن‌ها ارسال شده تطبیق داده می‌شود. اگر گزینه storeonxref در inn.conf برابر true باشد، این الگو با نام‌های گروه‌های خبری در بدنه فیلد سربرگ Xref تطبیق داده خواهد شد؛ در غیر این صورت، با نام‌های گروه‌های خبری در بدنه فیلد سربرگ Newsgroups مطابقت داده می‌شود (برای بررسی تفاوت‌های میان این حالت‌ها به inn.conf(5) مراجعه کنید). عبارت‌های مسموم wildmat (عبارت‌هایی که با "@" آغاز می‌شوند) مجاز هستند و می‌توان از آن‌ها برای مستثنی کردن الگوهای گروهی خاص استفاده کرد: مقالاتی که به صورت متقابل در گروه‌های خبری مسموم نیز ارسال (crosspost) شده باشند، با این روش ذخیره‌سازی نگهداری نخواهند شد. الگوی <wildmat> به ترتیب بررسی و تطبیق داده می‌شود.

هیچ الگوی پیش‌فرضی برای گروه‌های خبری وجود ندارد؛ اگر یک مدخل باید با تمام گروه‌های خبری مطابقت کند، به صراحت از "newsgroups: *" استفاده کنید.

class: <storage_class>

یک شناسه برای این مدخل روش ذخیره‌سازی است. مقدار <storage_class> باید عددی بین ۰ تا ۲۵۵ باشد. این شناسه باید در بین تمام مدخل‌های این پرونده یکتا باشد. این مقدار عمدتاً برای مشخص کردن زمان‌های انقضا بر اساس کلاس ذخیره‌سازی طبق توضیحات expire.ctl(5) به کار می‌رود؛ همچنین "timehash" و "timecaf" پوشه سطح بالایی را که مقالات پذیرفته‌شده توسط این کلاس ذخیره‌سازی در آن ذخیره می‌شوند تنظیم خواهند کرد. به عنوان مثال، کلاس‌های ذخیره‌سازی را می‌توان به صورت ترتیبی در storage.conf شماره‌گذاری کرد.

تخصیص یک شماره مشخص به یک کلاس ذخیره‌سازی اختیاری اما دائمی است (زیرا در توکن‌های ذخیره‌سازی استفاده می‌شود). در واقع، یک مقاله بر اساس قوانین ذخیره‌سازی حاکم در زمان ورودش به یک کلاس ذخیره‌سازی اختصاص می‌یابد. این شناسه حتی اگر storage.conf بعداً تغییر کند و همان مقاله در صورت دریافت پس از آن تغییر به کلاس ذخیره‌سازی دیگری اختصاص می‌یافت، تغییر نخواهد کرد. مقاله همچنان کاملاً معتبر و قابل بازیابی است. تنها تفاوت برای فرآیند انقضا با تنظیم groupbaseexpiry روی false در inn.conf خواهد بود: قوانین موجود در expire.ctl روی کلاس ذخیره‌سازی اعمال می‌شوند که در بدو ورود به مقالات اختصاص یافته است.

size: <minsize>[,<maxsize>]

محدوده‌ای از اندازه مقاله‌ها (به بایت) که باید با این روش ذخیره‌سازی نگهداری شوند. اگر مقدار <maxsize> برابر "0" باشد یا ذکر نشود، حد بالای اندازه مقاله‌ها صرفاً با مقدار maxartsize در inn.conf محدود می‌شود. فیلد size: اختیاری است و چنانچه بخواهید مقاله‌ها با هر اندازه‌ای در این روش ذخیره‌سازی نگهداری شوند (البته به شرطی که این مقاله‌ها تمام شرایط دیگر این مدخل روش ذخیره‌سازی را برآورده کنند)، می‌توان آن را کاملاً حذف کرد. به صورت پیش‌فرض، مقدار <minsize> برابر "0" تنظیم شده است.

expires: <mintime>[,<maxtime>]

محدوده‌ای از زمان‌های انقضای مقاله که باید با استفاده از این روش ذخیره‌سازی نگهداری شوند. دقت کنید؛ این کلید کاربرد کمتری نسبت به آنچه در ابتدا به نظر می‌رسد دارد. این معیار صرفاً بر اساس فیلد سربرگ Expires خود مقاله است، نه بر اساس هیچ‌یک از سیاست‌های محلی انقضا یا موارد موجود در expire.ctl! اگر مقدار <mintime> غیر صفر باشد، این مدخل با هیچ مقاله‌ای که فاقد فیلد سربرگ Expires باشد مطابقت نخواهد داشت. بنابراین این کلید واقعاً تنها برای تخصیص مقالاتی با زمان‌های انقضای درخواستی طولانی‌تر به یک روش ذخیره‌سازی مجزا مفید است. مقاله‌ها تنها زمانی مطابقت پیدا می‌کنند که زمان باقی‌مانده تا انقضا (یعنی مدت زمانی در آینده که فیلد سربرگ Expires مقاله درخواست می‌کند باقی بماند) در بازه مشخص‌شده توسط <mintime> و <maxtime> قرار گیرد.

قالب این پارامترها به صورت "0d0h0m0s" (روزها، ساعت‌ها، دقیقه‌ها و ثانیه‌ها در آینده) است. اگر <maxtime> برابر "0s" باشد یا مشخص نشود، هیچ حد بالایی برای زمان‌های انقضایی که در این مدخل قرار می‌گیرند وجود ندارد (توجه داشته باشید که این کلید هیچ تأثیری بر زمان انقضای واقعی مقاله ندارد، بلکه صرفاً مشخص می‌کند که آیا مقاله با این روش ذخیره‌سازی ذخیره می‌شود یا خیر). این فیلد نیز اختیاری است و اگر مایل نیستید مقاله‌ها را بر اساس فیلد سربرگ Expires آن‌ها (در صورت وجود) ذخیره کنید، می‌توانید آن را به کلی حذف نمایید.

مقدار <mintime> بزرگتر از "0s" به این معنی است که این روش ذخیره‌سازی با هیچ مقاله‌ای که فاقد فیلد سربرگ Expires باشد مطابقت نخواهد داشت.

options: <options>

این کلید برای ارسال گزینه‌های ویژه به روش‌های ذخیره‌سازی است که به آن‌ها نیاز دارند (در حال حاضر تنها "cnfs"). برای شرح کاربرد آن، بخش «روش‌های ذخیره‌سازی (STORAGE METHODS)» را در ادامه ببینید.

exactmatch: <bool>

اگر این کلید روی true تنظیم شود، تمامی گروه‌های خبری در بدنه فیلد سربرگ Newsgroups (یا در صورت فعال بودن storeonxref در inn.conf، هدر Xref) مقاله‌های ورودی بررسی می‌شوند تا مشخص شود آیا با الگوهای گروه‌های خبری مطابقت دارند یا خیر. (به طور معمول، هر تعداد غیر صفر از گروه‌های خبری منطبق کافی است، به شرطی که هیچ گروه خبری با الگوی مسموم wildmat همان‌طور که در بالا توضیح داده شد مطابقت نداشته باشد). این یک مقدار بولی (منطقی) است؛ مقادیر "true"، "yes" و "on" برای فعال کردن این کلید قابل استفاده هستند. بزرگی و کوچکی حروف در این مقادیر بی‌اهمیت است. مقدار پیش‌فرض false است.

filtered: <bool>

اگر این کلید روی true تنظیم شود، مقاله باید توسط هر یک از فیلترهای مقاله فعال (Perl یا Python) برای innd رد شده باشد. این امر همچنین نیازمند این است که dontrejectfiltered در inn.conf روی true تنظیم شده باشد. مقاله‌های فیلترشده معمولاً در یک بافر کوچک CNFS یا روش ذخیره‌سازی دیگری با خط‌مشی انقضای نسبتاً سخت‌گیرانه نگهداری می‌شوند. این یک مقدار بولی است؛ "true"، "yes" و "on" برای فعال کردن این کلید قابل استفاده هستند. بزرگی و کوچکی حروف در این مقادیر تأثیری ندارد. مقدار پیش‌فرض false است.

اگر این کلید برای تمام کلاس‌های ذخیره‌سازی روی false تنظیم شده باشد، مقاله‌های فیلترشده در همان کلاس ذخیره‌سازی مقاله‌های پذیرفته‌شده نگهداری می‌شوند. تنها زمانی که حداقل یک کلاس ذخیره‌سازی این کلید را روی true تنظیم کرده باشد، مقاله‌های فیلترشده و مقاله‌های پذیرفته‌شده دیگر در هیچ کلاس ذخیره‌سازی با یکدیگر به صورت مخلوط ذخیره نخواهند شد.

path: <wildmat>

مشخص می‌کند چه مقالاتی بر اساس فیلد سربرگ Path خود با استفاده از این روش ذخیره‌سازی نگهداری شوند. مقدار <wildmat> یک الگوی uwildmat است که با بدنه فیلد سربرگ Path مقالات تطبیق داده می‌شود؛ این فیلد نشان‌دهنده مسیر عبور مقالات یا مبدا ارسال آن‌هاست. عبارت‌های مسموم wildmat (عبارت‌هایی که با "@" شروع می‌شوند) مجاز هستند و می‌توان از آن‌ها برای استثنا کردن الگوهای مسیر خاص استفاده کرد (به جای عبارت‌هایی که با "!" شروع می‌شوند، چرا که به دلیل معنای خاص "!" در فیلدهای سربرگ Path، به عنوان نفی در نظر گرفته نمی‌شوند). الگوی <wildmat> به ترتیب بررسی و تطبیق داده می‌شود.

یک نمونه کاربرد رایج می‌تواند ذخیره مقاله‌های ارسالی از یک سایت هرزنامه در یک بافر کوچک CNFS باشد تا از تأثیر منفی آن بر مدت نگهداری کلی مقالات جلوگیری شود:

path: "*!spam-site.example.com!not-for-mail"

حالت پیش‌فرض تطبیق با همه مقاله‌ها است.

اگر مقاله‌ای با تمام محدودیت‌های یک مدخل مطابقت داشته باشد، از طریق آن روش ذخیره‌سازی نگهداری شده و به آن <storage_class> مرتبط می‌شود. این پرونده به ترتیب پویش می‌شود و اولین مدخل منطبق برای ذخیره مقاله به کار می‌رود.

اگر مقاله‌ای با هیچ مدخلی مطابقت نداشته باشد، چه به دلیل ارسال شدن به گروه خبری که با هیچ‌یک از الگوهای <wildmat> مطابقت ندارد و چه به دلیل خارج بودن از محدوده‌های اندازه و انقضای تمام مدخل‌هایی که الگوی گروه خبری آن‌ها منطبق بوده است، مقاله ذخیره نشده و توسط innd رد می‌شود. هنگامی که این اتفاق رخ دهد، پیام خطای:

cant store article: no matching entry in storage.conf

در syslog ثبت می‌شود. اگر می‌خواهید مقاله‌های منطبق با الگوهای گروه خبری یا محدوده‌های اندازه یا انقضای خاص را بدون اعلام خطا کنار بگذارید، به جای اینکه اجازه دهید با هیچ مدخل روش ذخیره‌سازی مطابقت نکنند، آن‌ها را به روش ذخیره‌سازی "trash" اختصاص دهید.

روش‌های ذخیره‌سازی (STORAGE METHODS)

در حال حاضر پنج روش ذخیره‌سازی در دسترس است. هر روش مزایا و معایب خود را دارد؛ شما می‌توانید هر ترکیبی از آن‌ها را که متناسب با محیط شما باشد انتخاب کنید. توجه داشته باشید که هر روش دارای صفت EXPENSIVESTAT است که نشان می‌دهد آیا بررسی وجود یک مقاله پرهزینه است یا خیر. این ویژگی برای اجرای expireover(8) به کار می‌رود.

cnfs

روش ذخیره‌سازی "cnfs" مقاله‌ها را در بافرهای چرخشی بزرگ ذخیره می‌کند (CNFS مخفف Cyclic News File System است). مقاله‌ها در بافرهای CNFS به ترتیب ورود ذخیره می‌شوند، و هنگامی که بافر پر شود، چرخش کرده و از ابتدای بافر شروع به ذخیره مقاله‌های جدید روی قدیمی‌ترین مقاله‌های موجود در بافر می‌کند. بنابراین زمان انقضای مقاله‌های ذخیره‌شده در بافرهای CNFS کاملاً با این موضوع تعیین می‌شود که چرخش کامل بافر چقدر طول می‌کشد، که خود به سرعت ذخیره شدن داده‌ها در آن بستگی دارد. (از این رو گفته می‌شود این روش قابلیت خودانقضایی دارد. این همچنین بدان معناست که وقتی مقاله‌ای لغو می‌شود، cycbuff بازنمی‌گردد تا فضا را آزاد کند مگر زمانی که بافر دوباره دور بزند و استفاده مجدد از کل cycbuff آغاز شود). مقدار EXPENSIVESTAT برای این روش false است.

سامانه CNFS پرونده پیکربندی مخصوص به خود را با نام cycbuff.conf دارد که برخی ظرافت‌های مربوط به توضیحات پایه فوق در آن شرح داده شده است. مدخل‌های روش ذخیره‌سازی برای روش "cnfs" باید دارای یک فیلد options: باشند که metacycbuff مورد نظر برای ذخیره مقاله‌های منطبق با آن مدخل را مشخص کند؛ برای جزئیات مربوط به metacycbuff به cycbuff.conf(5) مراجعه کنید.

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

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

timecaf

این روش چندین مقاله را در یک پرونده ذخیره می‌کند، که نام آن بر اساس زمان ورود مقاله و کلاس ذخیره‌سازی تعیین می‌شود. نام پرونده به صورت زیر خواهد بود:

<patharticles>/timecaf-nn/bb/aacc.CF

که در آن "nn" مقدار هگزادسیمال <storage_class>، و "bb" و "aacc" بخش‌های هگزادسیمال زمان ورود هستند، و "CF" یک پسوند ثابت (کدگذاری‌شده در برنامه) است. (زمان ورود، بر حسب ثانیه‌های سپری‌شده از مبدا یونیکس، به هگزادسیمال تبدیل شده و به صورت "0xaabbccdd" تفسیر می‌شود که در آن از "aa"، "bb" و "cc" برای ساخت مسیر استفاده می‌گردد). این روش قابلیت خودانقضایی ندارد (بدین معنی که برنامه expire باید به صورت دوره‌ای اجرا شود تا مقاله‌های قدیمی، و همچنین مقاله‌های لغوشده در صورتی که immediatecancel در inn.conf روی true نباشد را حذف کند). مقدار EXPENSIVESTAT برای این روش false است.

یک پرونده CAF مشخص شامل تمامی مقاله‌های دریافت شده در بازه زمانی حدوداً ۴ دقیقه‌ای (۲۵۶ ثانیه‌ای) است، و به ۲۶۲٬۱۴۴ مقاله و حدود ۳٫۵ گیگابایت محدود می‌شود. این مقدار برای عملیات عادی کافی است. تنها نکته قابل توجه زمانی است که دسته‌های مقالات را با سرعت بالا میان دو سرور تغذیه می‌کنید؛ در آن صورت مایل خواهید بود آن را به این تعداد مقاله در بازه زمانی که یک پرونده CAF مقالات تازه وارد را ذخیره می‌کند، محدود کنید.

مزایا: در نوشتن مقالات تقریباً چهار برابر سریع‌تر از "timehash" است، زیرا بخش زیادی از سربار سیستم‌فایل نادیده گرفته می‌شود، در حالی که همچنان همان کنترل دقیق بر زمان نگهداری مقاله‌ها حفظ می‌گردد.

معایب: استفاده از این روش به معنای صرف‌نظر کردن از دستکاری‌های دستی اسپول مقالات است (به جز دقیق‌ترین موارد)؛ از این جهت شبیه به "cnfs" عمل می‌کند. به عنوان یکی از روش‌های ذخیره‌سازی جدیدتر و کم‌تر به‌کاررفته، "timecaf" به اندازه روش‌های دیگر به صورت گسترده آزمایش نشده است. این روش نیازمند اجرای یک برنامه شبانه expire برای حذف مقاله‌های قدیمی است، که این کار با فشرده‌سازی پرونده‌های CAF (در صورتی که هنوز حاوی مقاله‌های دردسترس باشند) یا حذف آن‌ها انجام می‌شود.

timehash

این روش بسیار شبیه به "timecaf" است با این تفاوت که هر مقاله در یک پرونده جداگانه ذخیره می‌شود. نام پرونده برای یک مقاله مشخص به صورت زیر خواهد بود:

<patharticles>/time-nn/bb/cc/yyyy-aadd

که در آن "nn" مقدار هگزادسیمال <storage_class>، "yyyy" یک شماره ترتیب هگزادسیمال، و "bb"، "cc" و "aadd" بخش‌های زمان ورود به هگزادسیمال هستند (زمان ورود همان‌طور که در بالا ذیل "timecaf" مستند شده تفسیر می‌شود). این روش قابلیت خودانقضایی ندارد. مقاله‌های لغوشده بلافاصله حذف می‌شوند. مقدار EXPENSIVESTAT برای این روش true است.

مزایا: گروه‌های با ترافیک سنگین باعث ایجاد گلوگاه نمی‌شوند، و کنترل دقیق بر زمان نگهداری مقاله‌ها همچنان امکان‌پذیر است.

معایب: توانایی یافتن آسان همه مقاله‌ها در یک گروه خبری مشخص و دستکاری دستی اسپول مقاله از دست می‌رود، و INN همچنان از افت سرعت ناشی از سربار سیستم‌فایل (ایجاد و حذف تک‌تک پرونده‌ها عملیاتی کند است) و مصرف بالاتر inode رنج می‌برد. همچنین این روش نیازمند اجرای یک برنامه شبانه expire برای حذف مقاله‌های قدیمی از اسپول اخبار است.

tradspool

اسپول سنتی یا "tradspool"، قالب سنتی ذخیره‌سازی مقاله‌های خبری است. هر مقاله در یک پرونده متنی مجزا با نام زیر نگهداری می‌شود:

<patharticles>/news/group/name/nnnnn

که در آن "news/group/name" نام گروه خبری است که مقاله به آن ارسال شده و هر نقطه به یک اسلش تبدیل شده است، و "nnnnn" شماره ترتیب مقاله در آن گروه خبری است. برای مقالاتی که به چندین گروه ارسال شده‌اند (crossposted)، مقاله با هر یک از گروه‌های خبری که به آن ارسال شده پیوند داده می‌شود (با استفاده از پیوندهای سخت یا نمادین). این روشی است که نسخه‌های INN پیش از ۲.۰ تمام مقالات را ذخیره می‌کردند، و همچنین فرمت ذخیره‌سازی مقاله‌ای است که توسط C News و سیستم‌های خبری اولیه استفاده می‌شد. این روش قابلیت خودانقضایی ندارد. مقاله‌های لغوشده بلافاصله حذف می‌شوند. مقدار EXPENSIVESTAT برای این روش true است.

مزایا: به طور گسترده استفاده شده و به خوبی شناخته شده است؛ می‌تواند اسپول‌های مقاله‌ای را که توسط نسخه‌های قدیمی‌تر INN نوشته شده‌اند بخواند و با تمام افزونه‌های شخص ثالث INN سازگار است. این سازوکار ذخیره‌سازی دسترسی آسان و مستقیم به مقالات ذخیره‌شده در سرور را فراهم می‌کند، نوشتن برنامه‌هایی را که با اسپول اخبار سروکار دارند بسیار آسان می‌سازد، کنترل دقیقی بر زمان‌های نگهداری مقاله می‌دهد، و همراه با ابزار کمکی scanspool برای انجام بررسی‌های سلامت ارائه می‌شود.

معایب: به دلیل سربار سیستم‌فایل، در مقایسه با روش‌های ذخیره‌سازی cnfs و timecaf به سیستم‌فایل و سیستم ورودی/خروجی سریع‌تری نیاز دارد. گروه‌های پرتردد به دلیل ناکارآمدی ذخیره تعداد زیادی پرونده مقاله در یک دایرکتوری واحد، تمایل به ایجاد گلوگاه دارند. این روش inodeهای بیشتری مصرف می‌کند و به اجرای یک برنامه شبانه expire برای حذف مقاله‌های قدیمی از اسپول اخبار نیاز دارد.

trash

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

مثال‌ها (EXAMPLES)

پرونده نمونه storage.conf زیر تمام مقاله‌های ارسال‌شده به alt.binaries.* را در metacycbuff بافر CNFS با نام "BINARIES"، تمام مقاله‌های با اندازه تقریبی بیش از ۵۰ کیلوبایت در هر سلسله‌مراتب دیگر را در metacycbuff بافر CNFS با نام "LARGE"، تمام مقاله‌های دیگر در alt.* را در یک کلاس timehash، و تمام مقاله‌های دیگر در هر گروه خبری را در کلاس دوم timehash ذخیره می‌کند؛ به استثنای سلسله‌مراتب internal.* که در قالب اسپول سنتی نگهداری می‌شود.

method tradspool {
    class: 1
    newsgroups: internal.*
}
method cnfs {
    class: 2
    newsgroups: alt.binaries.*
    options: BINARIES
}
method cnfs {
    class: 3
    newsgroups: *
    size: 50000
    options: LARGE
}
method timehash {
    class: 4
    newsgroups: alt.*
}
method timehash {
    class: 5
    newsgroups: *
}

توجه داشته باشید که آخرین مدخل روش ذخیره‌سازی همه موارد را دریافت خواهد کرد (Catch-all). این یک عادت خوب است؛ مطمئن شوید که حداقل یک مدخل همه‌گیر دارید تا در صورتی که چیزی غیرمنتظره پیش آمد، از قلم نیفتد. همچنین توجه کنید که قانون ویژه برای سلسله‌مراتب internal.* در ابتدا آمده است، بنابراین حتی مقالاتی را که به صورت مشترک به alt.binaries.* ارسال شده‌اند یا بیش از ۵۰ کیلوبایت اندازه دارند دریافت خواهد کرد.

در مورد عبارت‌های مسموم wildmat، اگر برای مثال مقاله‌ای داشته باشید که به طور همزمان بین misc.foo و misc.bar ارسال (crosspost) شده باشد، الگوی:

misc.*,!misc.bar

با آن مقاله مطابقت خواهد داشت، در حالی که الگوی:

misc.*,@misc.bar

با آن مقاله مطابقت نخواهد داشت. مقاله‌ای که تنها به misc.bar ارسال شده باشد با هیچ‌یک از این الگوها مطابقت نخواهد کرد.

معمولاً گروه‌های پرحجم و گروه‌هایی که مقاله‌های آن‌ها نیازی به نگهداری طولانی‌مدت ندارند (گروه‌های باینری، *.jobs*، news.lists.filters و غیره) در بافرهای CNFS ذخیره می‌شوند. برای سایر موارد از روش‌های دیگر (یا مجدداً بافرهای CNFS) استفاده کنید. با این وجود، در اغلب مواقع مناسب‌تر است که سلسله‌مراتب‌های ویژه مانند سلسله‌مراتب‌های محلی و سلسله‌مراتب‌هایی را که هرگز نباید منقضی شوند یا نیاز به بررسی دستی اسپول آن‌ها دارید، در "tradspool" نگهداری کنید.

تاریخچه (HISTORY)

نوشته‌شده توسط Katsuhiro Kondou <kondou@nec.co.jp> برای InterNetNews. بازنویسی‌شده به POD توسط Julien Elie.

همچنین ببینید (SEE ALSO)

cycbuff.conf(5), expire.ctl(5), expireover(8), inn.conf(5), innd(8), libinn_uwildmat(3), scanspool(8).