.\" -*- mode: troff; coding: utf-8 -*- .\" Automatically generated by Pod::Man 5.0102 (Pod::Simple 3.45) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. .ie n \{\ . ds C` "" . ds C' "" 'br\} .el\{\ . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "STORAGE.CONF 5" .TH STORAGE.CONF 5 2025-03-29 "INN 2.7.4" "InterNetNews Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "نام (NAME)" storage.conf \- پرونده پیکربندی برای مدیر ذخیره‌سازی .SH "توضیحات (DESCRIPTION)" .IX Header "DESCRIPTION" پرونده \fIpathetc\fR/storage.conf شامل قوانینی است که برای تخصیص مقاله‌ها به روش‌های مختلف ذخیره‌سازی استفاده می‌شوند. این قوانین تعیین می‌کنند که مقاله‌های ورودی در کجا ذخیره شوند. .PP مدیر ذخیره‌سازی یک واسط یکپارچه میان INN و انواع روش‌های مختلف ذخیره‌سازی است که به مدیر اخبار امکان می‌دهد بین روش‌های گوناگون ذخیره‌سازی با موازنه‌ها و مزایا و معایب مختلف انتخاب کند (یا حتی از چندین روش به‌طور همزمان برای گروه‌های خبری مختلف یا مقاله‌هایی با اندازه‌های متفاوت استفاده نماید). سایر بخش‌های INN نیازی ندارند بدانند برای یک مقاله مشخص از چه نوع روش ذخیره‌سازی استفاده شده است؛ مدیر ذخیره‌سازی هنگام بازیابی آن مقاله از طریق API ذخیره‌سازی، این موضوع را به‌طور خودکار تشخیص خواهد داد. توجه داشته باشید که ممکن است بخواهید گزینه‌های ارائه‌شده در .BR inn.conf (5) را نیز درباره ذخیره‌سازی مقاله‌ها بررسی کنید. .PP پرونده \fIstorage.conf\fR از مجموعه‌ای از مدخل‌های روش‌های ذخیره‌سازی تشکیل شده است. خطوط خالی و خطوطی که با علامت هش (\f(CW\*(C`#\*(C'\fR) آغاز می‌شوند نادیده گرفته خواهند شد. حداکثر تعداد نویسه‌ها در هر خط ۲۵۵ است. ترتیب مدخل‌ها در این پرونده اهمیت دارد؛ توضیحات زیر را ببینید. .PP هر مدخل، یک روش ذخیره‌سازی و مجموعه‌ای از قوانین را مشخص می‌کند. مقالاتی که با تمام قوانین یک مدخل روش ذخیره‌سازی مطابقت داشته باشند با استفاده از همان روش ذخیره‌سازی نگهداری خواهند شد؛ اگر مقاله‌ای با چندین مدخل روش ذخیره‌سازی مطابقت کند، اولین مدخل مورد استفاده قرار می‌گیرد. ساختار هر مدخل به صورت زیر است: .PP .Vb 10 \& method { \& newsgroups: \& class: \& size: [,] \& expires: [,] \& options: \& exactmatch: \& filtered: \& path: \& } .Ve .PP اگر فاصله یا تب در یک مقدار گنجانده شده باشد، آن مقدار باید درون علامت‌های نقل‌قول دوتایی ("") محصور شود. اگر بخواهید علامت هش (\f(CW\*(C`#\*(C'\fR) یا نقل‌قول دوتایی را دقیقاً به صورت تحت‌اللفظی در یک مقدار درج کنید، باید با \f(CW\*(C`\e\*(C'\fR اسکیپ شوند. .PP مقدار نام روش ذخیره‌سازی است که باید برای مقاله‌های منطبق با قوانین این مدخل استفاده شود. روش‌های ذخیره‌سازی که در حال حاضر در دسترس هستند عبارتند از: .PP .Vb 5 \& cnfs \& timecaf \& timehash \& tradspool \& trash .Ve .PP برای جزئیات بیشتر بخش «روش‌های ذخیره‌سازی (STORAGE METHODS)» را در ادامه ببینید. .PP معانی کلیدها در هر مدخل روش ذخیره‌سازی به شرح زیر است: .IP "\fInewsgroups\fR: " 4 .IX Item "newsgroups: " مشخص می‌کند چه گروه‌های خبری با این روش ذخیره‌سازی نگهداری شوند. مقدار یک الگوی \&\fIuwildmat\fR است که با گروه‌های خبری که مقاله به آن‌ها ارسال شده تطبیق داده می‌شود. اگر گزینه \fIstoreonxref\fR در \fIinn.conf\fR برابر true باشد، این الگو با نام‌های گروه‌های خبری در بدنه فیلد سربرگ Xref تطبیق داده خواهد شد؛ در غیر این صورت، با نام‌های گروه‌های خبری در بدنه فیلد سربرگ Newsgroups مطابقت داده می‌شود (برای بررسی تفاوت‌های میان این حالت‌ها به .BR inn.conf (5) مراجعه کنید). عبارت‌های مسموم wildmat (عبارت‌هایی که با \f(CW\*(C`@\*(C'\fR آغاز می‌شوند) مجاز هستند و می‌توان از آن‌ها برای مستثنی کردن الگوهای گروهی خاص استفاده کرد: مقالاتی که به صورت متقابل در گروه‌های خبری مسموم نیز ارسال (crosspost) شده باشند، با این روش ذخیره‌سازی نگهداری نخواهند شد. الگوی به ترتیب بررسی و تطبیق داده می‌شود. .Sp هیچ الگوی پیش‌فرضی برای گروه‌های خبری وجود ندارد؛ اگر یک مدخل باید با تمام گروه‌های خبری مطابقت کند، به صراحت از \f(CW\*(C`newsgroups: *\*(C'\fR استفاده کنید. .IP "\fIclass\fR: " 4 .IX Item "class: " یک شناسه برای این مدخل روش ذخیره‌سازی است. مقدار باید عددی بین ۰ تا ۲۵۵ باشد. این شناسه باید در بین تمام مدخل‌های این پرونده یکتا باشد. این مقدار عمدتاً برای مشخص کردن زمان‌های انقضا بر اساس کلاس ذخیره‌سازی طبق توضیحات .BR expire.ctl (5) به کار می‌رود؛ همچنین \f(CW\*(C`timehash\*(C'\fR و \f(CW\*(C`timecaf\*(C'\fR پوشه سطح بالایی را که مقالات پذیرفته‌شده توسط این کلاس ذخیره‌سازی در آن ذخیره می‌شوند تنظیم خواهند کرد. به عنوان مثال، کلاس‌های ذخیره‌سازی را می‌توان به صورت ترتیبی در \&\fIstorage.conf\fR شماره‌گذاری کرد. .Sp تخصیص یک شماره مشخص به یک کلاس ذخیره‌سازی اختیاری اما دائمی است (زیرا در توکن‌های ذخیره‌سازی استفاده می‌شود). در واقع، یک مقاله بر اساس قوانین ذخیره‌سازی حاکم در زمان ورودش به یک کلاس ذخیره‌سازی اختصاص می‌یابد. این شناسه حتی اگر \fIstorage.conf\fR بعداً تغییر کند و همان مقاله در صورت دریافت پس از آن تغییر به کلاس ذخیره‌سازی دیگری اختصاص می‌یافت، تغییر نخواهد کرد. مقاله همچنان کاملاً معتبر و قابل بازیابی است. تنها تفاوت برای فرآیند انقضا با تنظیم \fIgroupbaseexpiry\fR روی false در \fIinn.conf\fR خواهد بود: قوانین موجود در \fIexpire.ctl\fR روی کلاس ذخیره‌سازی اعمال می‌شوند که در بدو ورود به مقالات اختصاص یافته است. .IP "\fIsize\fR: [,]" 4 .IX Item "size: [,]" محدوده‌ای از اندازه مقاله‌ها (به بایت) که باید با این روش ذخیره‌سازی نگهداری شوند. اگر مقدار برابر \f(CW\*(C`0\*(C'\fR باشد یا ذکر نشود، حد بالای اندازه مقاله‌ها صرفاً با مقدار \fImaxartsize\fR در \fIinn.conf\fR محدود می‌شود. فیلد size: اختیاری است و چنانچه بخواهید مقاله‌ها با هر اندازه‌ای در این روش ذخیره‌سازی نگهداری شوند (البته به شرطی که این مقاله‌ها تمام شرایط دیگر این مدخل روش ذخیره‌سازی را برآورده کنند)، می‌توان آن را کاملاً حذف کرد. به صورت پیش‌فرض، مقدار برابر \f(CW\*(C`0\*(C'\fR تنظیم شده است. .IP "\fIexpires\fR: [,]" 4 .IX Item "expires: [,]" محدوده‌ای از زمان‌های انقضای مقاله که باید با استفاده از این روش ذخیره‌سازی نگهداری شوند. دقت کنید؛ این کلید کاربرد کمتری نسبت به آنچه در ابتدا به نظر می‌رسد دارد. این معیار \fBصرفاً\fR بر اساس فیلد سربرگ Expires خود مقاله است، نه بر اساس هیچ‌یک از سیاست‌های محلی انقضا یا موارد موجود در \fIexpire.ctl\fR! اگر مقدار غیر صفر باشد، این مدخل با هیچ مقاله‌ای که فاقد فیلد سربرگ Expires باشد \fBمطابقت نخواهد داشت\fR. بنابراین این کلید واقعاً تنها برای تخصیص مقالاتی با زمان‌های انقضای درخواستی طولانی‌تر به یک روش ذخیره‌سازی مجزا مفید است. مقاله‌ها تنها زمانی مطابقت پیدا می‌کنند که زمان باقی‌مانده تا انقضا (یعنی مدت زمانی در آینده که فیلد سربرگ Expires مقاله درخواست می‌کند باقی بماند) در بازه مشخص‌شده توسط و قرار گیرد. .Sp قالب این پارامترها به صورت \f(CW\*(C`0d0h0m0s\*(C'\fR (روزها، ساعت‌ها، دقیقه‌ها و ثانیه‌ها در آینده) است. اگر برابر \f(CW\*(C`0s\*(C'\fR باشد یا مشخص نشود، هیچ حد بالایی برای زمان‌های انقضایی که در این مدخل قرار می‌گیرند وجود ندارد (توجه داشته باشید که این کلید هیچ تأثیری بر زمان انقضای واقعی مقاله ندارد، بلکه صرفاً مشخص می‌کند که آیا مقاله با این روش ذخیره‌سازی ذخیره می‌شود یا خیر). این فیلد نیز اختیاری است و اگر مایل نیستید مقاله‌ها را بر اساس فیلد سربرگ Expires آن‌ها (در صورت وجود) ذخیره کنید، می‌توانید آن را به کلی حذف نمایید. .Sp مقدار بزرگتر از \f(CW\*(C`0s\*(C'\fR به این معنی است که این روش ذخیره‌سازی با هیچ مقاله‌ای که فاقد فیلد سربرگ Expires باشد مطابقت نخواهد داشت. .IP "\fIoptions\fR: " 4 .IX Item "options: " این کلید برای ارسال گزینه‌های ویژه به روش‌های ذخیره‌سازی است که به آن‌ها نیاز دارند (در حال حاضر تنها \f(CW\*(C`cnfs\*(C'\fR). برای شرح کاربرد آن، بخش «روش‌های ذخیره‌سازی (STORAGE METHODS)» را در ادامه ببینید. .IP "\fIexactmatch\fR: " 4 .IX Item "exactmatch: " اگر این کلید روی true تنظیم شود، تمامی گروه‌های خبری در بدنه فیلد سربرگ Newsgroups (یا در صورت فعال بودن \fIstoreonxref\fR در \fIinn.conf\fR، هدر Xref) مقاله‌های ورودی بررسی می‌شوند تا مشخص شود آیا با الگوهای گروه‌های خبری مطابقت دارند یا خیر. (به طور معمول، هر تعداد غیر صفر از گروه‌های خبری منطبق کافی است، به شرطی که هیچ گروه خبری با الگوی مسموم wildmat همان‌طور که در بالا توضیح داده شد مطابقت نداشته باشد). این یک مقدار بولی (منطقی) است؛ مقادیر \&\f(CW\*(C`true\*(C'\fR، \f(CW\*(C`yes\*(C'\fR و \f(CW\*(C`on\*(C'\fR برای فعال کردن این کلید قابل استفاده هستند. بزرگی و کوچکی حروف در این مقادیر بی‌اهمیت است. مقدار پیش‌فرض false است. .IP "\fIfiltered\fR: " 4 .IX Item "filtered: " اگر این کلید روی true تنظیم شود، مقاله باید توسط هر یک از فیلترهای مقاله فعال (Perl یا Python) برای \fBinnd\fR رد شده باشد. این امر همچنین نیازمند این است که \&\fIdontrejectfiltered\fR در \fIinn.conf\fR روی true تنظیم شده باشد. مقاله‌های فیلترشده معمولاً در یک بافر کوچک CNFS یا روش ذخیره‌سازی دیگری با خط‌مشی انقضای نسبتاً سخت‌گیرانه نگهداری می‌شوند. این یک مقدار بولی است؛ \&\f(CW\*(C`true\*(C'\fR، \f(CW\*(C`yes\*(C'\fR و \f(CW\*(C`on\*(C'\fR برای فعال کردن این کلید قابل استفاده هستند. بزرگی و کوچکی حروف در این مقادیر تأثیری ندارد. مقدار پیش‌فرض false است. .Sp اگر این کلید برای تمام کلاس‌های ذخیره‌سازی روی false تنظیم شده باشد، مقاله‌های فیلترشده در همان کلاس ذخیره‌سازی مقاله‌های پذیرفته‌شده نگهداری می‌شوند. تنها زمانی که حداقل یک کلاس ذخیره‌سازی این کلید را روی true تنظیم کرده باشد، مقاله‌های فیلترشده و مقاله‌های پذیرفته‌شده دیگر در هیچ کلاس ذخیره‌سازی با یکدیگر به صورت مخلوط ذخیره نخواهند شد. .IP "\fIpath\fR: " 4 .IX Item "path: " مشخص می‌کند چه مقالاتی بر اساس فیلد سربرگ Path خود با استفاده از این روش ذخیره‌سازی نگهداری شوند. مقدار یک الگوی \&\fIuwildmat\fR است که با بدنه فیلد سربرگ Path مقالات تطبیق داده می‌شود؛ این فیلد نشان‌دهنده مسیر عبور مقالات یا مبدا ارسال آن‌هاست. عبارت‌های مسموم wildmat (عبارت‌هایی که با \&\f(CW\*(C`@\*(C'\fR شروع می‌شوند) مجاز هستند و می‌توان از آن‌ها برای استثنا کردن الگوهای مسیر خاص استفاده کرد (به جای عبارت‌هایی که با \f(CW\*(C`!\*(C'\fR شروع می‌شوند، چرا که به دلیل معنای خاص \&\f(CW\*(C`!\*(C'\fR در فیلدهای سربرگ Path، به عنوان نفی در نظر گرفته نمی‌شوند). الگوی به ترتیب بررسی و تطبیق داده می‌شود. .Sp یک نمونه کاربرد رایج می‌تواند ذخیره مقاله‌های ارسالی از یک سایت هرزنامه در یک بافر کوچک CNFS باشد تا از تأثیر منفی آن بر مدت نگهداری کلی مقالات جلوگیری شود: .Sp .Vb 1 \& path: "*!spam\-site.example.com!not\-for\-mail" .Ve .Sp حالت پیش‌فرض تطبیق با همه مقاله‌ها است. .PP اگر مقاله‌ای با تمام محدودیت‌های یک مدخل مطابقت داشته باشد، از طریق آن روش ذخیره‌سازی نگهداری شده و به آن مرتبط می‌شود. این پرونده به ترتیب پویش می‌شود و اولین مدخل منطبق برای ذخیره مقاله به کار می‌رود. .PP اگر مقاله‌ای با هیچ مدخلی مطابقت نداشته باشد، چه به دلیل ارسال شدن به گروه خبری که با هیچ‌یک از الگوهای مطابقت ندارد و چه به دلیل خارج بودن از محدوده‌های اندازه و انقضای تمام مدخل‌هایی که الگوی گروه خبری آن‌ها منطبق بوده است، مقاله ذخیره نشده و توسط \fBinnd\fR رد می‌شود. هنگامی که این اتفاق رخ دهد، پیام خطای: .PP .Vb 1 \& cant store article: no matching entry in storage.conf .Ve .PP در syslog ثبت می‌شود. اگر می‌خواهید مقاله‌های منطبق با الگوهای گروه خبری یا محدوده‌های اندازه یا انقضای خاص را بدون اعلام خطا کنار بگذارید، به جای اینکه اجازه دهید با هیچ مدخل روش ذخیره‌سازی مطابقت نکنند، آن‌ها را به روش ذخیره‌سازی \f(CW\*(C`trash\*(C'\fR اختصاص دهید. .SH "روش‌های ذخیره‌سازی (STORAGE METHODS)" .IX Header "STORAGE METHODS" در حال حاضر پنج روش ذخیره‌سازی در دسترس است. هر روش مزایا و معایب خود را دارد؛ شما می‌توانید هر ترکیبی از آن‌ها را که متناسب با محیط شما باشد انتخاب کنید. توجه داشته باشید که هر روش دارای صفت EXPENSIVESTAT است که نشان می‌دهد آیا بررسی وجود یک مقاله پرهزینه است یا خیر. این ویژگی برای اجرای .BR expireover (8) به کار می‌رود. .IP \fBcnfs\fR 4 .IX Item "cnfs" روش ذخیره‌سازی \f(CW\*(C`cnfs\*(C'\fR مقاله‌ها را در بافرهای چرخشی بزرگ ذخیره می‌کند (CNFS مخفف Cyclic News File System است). مقاله‌ها در بافرهای CNFS به ترتیب ورود ذخیره می‌شوند، و هنگامی که بافر پر شود، چرخش کرده و از ابتدای بافر شروع به ذخیره مقاله‌های جدید روی قدیمی‌ترین مقاله‌های موجود در بافر می‌کند. بنابراین زمان انقضای مقاله‌های ذخیره‌شده در بافرهای CNFS کاملاً با این موضوع تعیین می‌شود که چرخش کامل بافر چقدر طول می‌کشد، که خود به سرعت ذخیره شدن داده‌ها در آن بستگی دارد. (از این رو گفته می‌شود این روش قابلیت خودانقضایی دارد. این همچنین بدان معناست که وقتی مقاله‌ای لغو می‌شود، cycbuff بازنمی‌گردد تا فضا را آزاد کند مگر زمانی که بافر دوباره دور بزند و استفاده مجدد از کل cycbuff آغاز شود). مقدار EXPENSIVESTAT برای این روش false است. .Sp سامانه CNFS پرونده پیکربندی مخصوص به خود را با نام \fIcycbuff.conf\fR دارد که برخی ظرافت‌های مربوط به توضیحات پایه فوق در آن شرح داده شده است. مدخل‌های روش ذخیره‌سازی برای روش \f(CW\*(C`cnfs\*(C'\fR باید دارای یک فیلد options: باشند که metacycbuff مورد نظر برای ذخیره مقاله‌های منطبق با آن مدخل را مشخص کند؛ برای جزئیات مربوط به metacycbuff به .BR cycbuff.conf (5) مراجعه کنید. .Sp مزایا: با اختلاف سریع‌ترین روش در میان تمام روش‌های ذخیره‌سازی است (به استثنای \f(CW\*(C`trash\*(C'\fR)، زیرا سربار کار با سیستم‌فایل و ایجاد فایل‌های جدید را حذف می‌کند. برخلاف تمام روش‌های دیگر ذخیره‌سازی، نیازی به انقضای دستی مقالات ندارد. با CNFS، سرور هرگز به دلیل پر شدن دیسک اسپول دچار افت سرعت یا توقف نخواهد شد، و گروه‌ها تنها به فایل‌های بافر مشخص‌شده محدود می‌شوند به طوری که هرگز نمی‌توانند بیش از مقدار فضای دیسک اختصاص‌یافته به خود مصرف کنند. .Sp معایب: کنترل زمان نگهداری مقاله‌ها دشوارتر است زیرا مقاله‌های قدیمی به طور خودکار بازنویسی می‌شوند. حملات به یوزنت، مانند ارسال سیل‌آسای پیام‌ها (Flooding) یا حجم انبوه هرزنامه، می‌تواند باعث شود مقاله‌های مورد نیاز بسیار سریع‌تر از حد انتظار (و بدون هیچ هشداری) منقضی شوند. .IP \fBtimecaf\fR 4 .IX Item "timecaf" این روش چندین مقاله را در یک پرونده ذخیره می‌کند، که نام آن بر اساس زمان ورود مقاله و کلاس ذخیره‌سازی تعیین می‌شود. نام پرونده به صورت زیر خواهد بود: .Sp .Vb 1 \& /timecaf\-nn/bb/aacc.CF .Ve .Sp که در آن \f(CW\*(C`nn\*(C'\fR مقدار هگزادسیمال ، و \f(CW\*(C`bb\*(C'\fR و \f(CW\*(C`aacc\*(C'\fR بخش‌های هگزادسیمال زمان ورود هستند، و \f(CW\*(C`CF\*(C'\fR یک پسوند ثابت (کدگذاری‌شده در برنامه) است. (زمان ورود، بر حسب ثانیه‌های سپری‌شده از مبدا یونیکس، به هگزادسیمال تبدیل شده و به صورت \f(CW\*(C`0xaabbccdd\*(C'\fR تفسیر می‌شود که در آن از \&\f(CW\*(C`aa\*(C'\fR، \f(CW\*(C`bb\*(C'\fR و \f(CW\*(C`cc\*(C'\fR برای ساخت مسیر استفاده می‌گردد). این روش قابلیت خودانقضایی ندارد (بدین معنی که برنامه \fBexpire\fR باید به صورت دوره‌ای اجرا شود تا مقاله‌های قدیمی، و همچنین مقاله‌های لغوشده در صورتی که \fIimmediatecancel\fR در \fIinn.conf\fR روی true نباشد را حذف کند). مقدار EXPENSIVESTAT برای این روش false است. .Sp یک پرونده CAF مشخص شامل تمامی مقاله‌های دریافت شده در بازه زمانی حدوداً ۴ دقیقه‌ای (۲۵۶ ثانیه‌ای) است، و به ۲۶۲٬۱۴۴ مقاله و حدود ۳٫۵ گیگابایت محدود می‌شود. این مقدار برای عملیات عادی کافی است. تنها نکته قابل توجه زمانی است که دسته‌های مقالات را با سرعت بالا میان دو سرور تغذیه می‌کنید؛ در آن صورت مایل خواهید بود آن را به این تعداد مقاله در بازه زمانی که یک پرونده CAF مقالات تازه وارد را ذخیره می‌کند، محدود کنید. .Sp مزایا: در نوشتن مقالات تقریباً چهار برابر سریع‌تر از \f(CW\*(C`timehash\*(C'\fR است، زیرا بخش زیادی از سربار سیستم‌فایل نادیده گرفته می‌شود، در حالی که همچنان همان کنترل دقیق بر زمان نگهداری مقاله‌ها حفظ می‌گردد. .Sp معایب: استفاده از این روش به معنای صرف‌نظر کردن از دستکاری‌های دستی اسپول مقالات است (به جز دقیق‌ترین موارد)؛ از این جهت شبیه به \&\f(CW\*(C`cnfs\*(C'\fR عمل می‌کند. به عنوان یکی از روش‌های ذخیره‌سازی جدیدتر و کم‌تر به‌کاررفته، \f(CW\*(C`timecaf\*(C'\fR به اندازه روش‌های دیگر به صورت گسترده آزمایش نشده است. این روش نیازمند اجرای یک برنامه شبانه \fBexpire\fR برای حذف مقاله‌های قدیمی است، که این کار با فشرده‌سازی پرونده‌های CAF (در صورتی که هنوز حاوی مقاله‌های دردسترس باشند) یا حذف آن‌ها انجام می‌شود. .IP \fBtimehash\fR 4 .IX Item "timehash" این روش بسیار شبیه به \f(CW\*(C`timecaf\*(C'\fR است با این تفاوت که هر مقاله در یک پرونده جداگانه ذخیره می‌شود. نام پرونده برای یک مقاله مشخص به صورت زیر خواهد بود: .Sp .Vb 1 \& /time\-nn/bb/cc/yyyy\-aadd .Ve .Sp که در آن \f(CW\*(C`nn\*(C'\fR مقدار هگزادسیمال ، \f(CW\*(C`yyyy\*(C'\fR یک شماره ترتیب هگزادسیمال، و \f(CW\*(C`bb\*(C'\fR، \f(CW\*(C`cc\*(C'\fR و \f(CW\*(C`aadd\*(C'\fR بخش‌های زمان ورود به هگزادسیمال هستند (زمان ورود همان‌طور که در بالا ذیل \f(CW\*(C`timecaf\*(C'\fR مستند شده تفسیر می‌شود). این روش قابلیت خودانقضایی ندارد. مقاله‌های لغوشده بلافاصله حذف می‌شوند. مقدار EXPENSIVESTAT برای این روش true است. .Sp مزایا: گروه‌های با ترافیک سنگین باعث ایجاد گلوگاه نمی‌شوند، و کنترل دقیق بر زمان نگهداری مقاله‌ها همچنان امکان‌پذیر است. .Sp معایب: توانایی یافتن آسان همه مقاله‌ها در یک گروه خبری مشخص و دستکاری دستی اسپول مقاله از دست می‌رود، و INN همچنان از افت سرعت ناشی از سربار سیستم‌فایل (ایجاد و حذف تک‌تک پرونده‌ها عملیاتی کند است) و مصرف بالاتر inode رنج می‌برد. همچنین این روش نیازمند اجرای یک برنامه شبانه \fBexpire\fR برای حذف مقاله‌های قدیمی از اسپول اخبار است. .IP \fBtradspool\fR 4 .IX Item "tradspool" اسپول سنتی یا \f(CW\*(C`tradspool\*(C'\fR، قالب سنتی ذخیره‌سازی مقاله‌های خبری است. هر مقاله در یک پرونده متنی مجزا با نام زیر نگهداری می‌شود: .Sp .Vb 1 \& /news/group/name/nnnnn .Ve .Sp که در آن \f(CW\*(C`news/group/name\*(C'\fR نام گروه خبری است که مقاله به آن ارسال شده و هر نقطه به یک اسلش تبدیل شده است، و \f(CW\*(C`nnnnn\*(C'\fR شماره ترتیب مقاله در آن گروه خبری است. برای مقالاتی که به چندین گروه ارسال شده‌اند (crossposted)، مقاله با هر یک از گروه‌های خبری که به آن ارسال شده پیوند داده می‌شود (با استفاده از پیوندهای سخت یا نمادین). این روشی است که نسخه‌های INN پیش از ۲.۰ تمام مقالات را ذخیره می‌کردند، و همچنین فرمت ذخیره‌سازی مقاله‌ای است که توسط C News و سیستم‌های خبری اولیه استفاده می‌شد. این روش قابلیت خودانقضایی ندارد. مقاله‌های لغوشده بلافاصله حذف می‌شوند. مقدار EXPENSIVESTAT برای این روش true است. .Sp مزایا: به طور گسترده استفاده شده و به خوبی شناخته شده است؛ می‌تواند اسپول‌های مقاله‌ای را که توسط نسخه‌های قدیمی‌تر INN نوشته شده‌اند بخواند و با تمام افزونه‌های شخص ثالث INN سازگار است. این سازوکار ذخیره‌سازی دسترسی آسان و مستقیم به مقالات ذخیره‌شده در سرور را فراهم می‌کند، نوشتن برنامه‌هایی را که با اسپول اخبار سروکار دارند بسیار آسان می‌سازد، کنترل دقیقی بر زمان‌های نگهداری مقاله می‌دهد، و همراه با ابزار کمکی \fBscanspool\fR برای انجام بررسی‌های سلامت ارائه می‌شود. .Sp معایب: به دلیل سربار سیستم‌فایل، در مقایسه با روش‌های ذخیره‌سازی cnfs و timecaf به سیستم‌فایل و سیستم ورودی/خروجی سریع‌تری نیاز دارد. گروه‌های پرتردد به دلیل ناکارآمدی ذخیره تعداد زیادی پرونده مقاله در یک دایرکتوری واحد، تمایل به ایجاد گلوگاه دارند. این روش inodeهای بیشتری مصرف می‌کند و به اجرای یک برنامه شبانه \fBexpire\fR برای حذف مقاله‌های قدیمی از اسپول اخبار نیاز دارد. .IP \fBtrash\fR 4 .IX Item "trash" این روش تمام مقاله‌هایی را که در آن ذخیره می‌شوند بی سر و صدا دور می‌ریزد (حذف می‌کند). تنها کاربردهای واقعی آن برای آزمایش و دور ریختن خاموش مقاله‌های منطبق با یک مدخل روش ذخیره‌سازی خاص (به هر دلیلی) است. مقاله‌های ذخیره‌شده در این روش هیچ فضای دیسکی اشغال نمی‌کنند و هرگز قابل بازیابی نیستند، بنابراین این روش نوعی قابلیت خودانقضایی دارد. مقدار EXPENSIVESTAT برای این روش false است. .SH "مثال‌ها (EXAMPLES)" .IX Header "EXAMPLES" پرونده نمونه \fIstorage.conf\fR زیر تمام مقاله‌های ارسال‌شده به alt.binaries.* را در metacycbuff بافر CNFS با نام \f(CW\*(C`BINARIES\*(C'\fR، تمام مقاله‌های با اندازه تقریبی بیش از ۵۰ کیلوبایت در هر سلسله‌مراتب دیگر را در metacycbuff بافر CNFS با نام \f(CW\*(C`LARGE\*(C'\fR، تمام مقاله‌های دیگر در alt.* را در یک کلاس timehash، و تمام مقاله‌های دیگر در هر گروه خبری را در کلاس دوم timehash ذخیره می‌کند؛ به استثنای سلسله‌مراتب internal.* که در قالب اسپول سنتی نگهداری می‌شود. .PP .Vb 10 \& 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: * \& } .Ve .PP توجه داشته باشید که آخرین مدخل روش ذخیره‌سازی همه موارد را دریافت خواهد کرد (Catch-all). این یک عادت خوب است؛ مطمئن شوید که حداقل یک مدخل همه‌گیر دارید تا در صورتی که چیزی غیرمنتظره پیش آمد، از قلم نیفتد. همچنین توجه کنید که قانون ویژه برای سلسله‌مراتب internal.* در ابتدا آمده است، بنابراین حتی مقالاتی را که به صورت مشترک به alt.binaries.* ارسال شده‌اند یا بیش از ۵۰ کیلوبایت اندازه دارند دریافت خواهد کرد. .PP در مورد عبارت‌های مسموم wildmat، اگر برای مثال مقاله‌ای داشته باشید که به طور همزمان بین misc.foo و misc.bar ارسال (crosspost) شده باشد، الگوی: .PP .Vb 1 \& misc.*,!misc.bar .Ve .PP با آن مقاله مطابقت خواهد داشت، در حالی که الگوی: .PP .Vb 1 \& misc.*,@misc.bar .Ve .PP با آن مقاله مطابقت نخواهد داشت. مقاله‌ای که تنها به misc.bar ارسال شده باشد با هیچ‌یک از این الگوها مطابقت نخواهد کرد. .PP معمولاً گروه‌های پرحجم و گروه‌هایی که مقاله‌های آن‌ها نیازی به نگهداری طولانی‌مدت ندارند (گروه‌های باینری، *.jobs*، news.lists.filters و غیره) در بافرهای CNFS ذخیره می‌شوند. برای سایر موارد از روش‌های دیگر (یا مجدداً بافرهای CNFS) استفاده کنید. با این وجود، در اغلب مواقع مناسب‌تر است که سلسله‌مراتب‌های ویژه مانند سلسله‌مراتب‌های محلی و سلسله‌مراتب‌هایی را که هرگز نباید منقضی شوند یا نیاز به بررسی دستی اسپول آن‌ها دارید، در \&\f(CW\*(C`tradspool\*(C'\fR نگهداری کنید. .SH "تاریخچه (HISTORY)" .IX Header "HISTORY" نوشته‌شده توسط Katsuhiro Kondou برای InterNetNews. بازنویسی‌شده به POD توسط Julien Elie. .SH "همچنین ببینید (SEE ALSO)" .IX Header "SEE ALSO" .BR cycbuff.conf (5), .BR expire.ctl (5), .BR expireover (8), .BR inn.conf (5), .BR innd (8), .BR libinn_uwildmat (3), .BR scanspool (8).