21

আমি যখন কোনও ফাইলে কোনও কমান্ডের আউটপুট পুনঃনির্দেশ করি (উদাহরণস্বরূপ echo Hello > file) সেই ফাইলটি কি কমান্ডটি প্রস্থান করার সাথে সাথে এই জাতীয় ডেটা থাকার নিশ্চয়তা পাবে? অথবা কমান্ডটি প্রস্থান করে এবং ফাইলটিতে লেখা ডেটার মধ্যে এখনও খুব ছোট উইন্ডো রয়েছে? কমান্ডটি প্রস্থান করার সাথে সাথেই আমি ফাইলটি পড়তে চাই, তবে আমি খালি ফাইলটি পড়তে চাই না।

— এরিক
সূত্র

1

এটি সম্ভবত অবিলম্বে কমান্ডটি কার্যকর করে, তবে ফাইলটি খোলার জন্য, লেখার জন্য এবং বন্ধ করতে যে পরিমাণ সময় লাগে তা আপনার হার্ড ড্রাইভ, চলমান যে কোনও প্রোগ্রাম ইত্যাদির গতি এবং ধরণের উপর নির্ভর করে

— ফ্রিজিনোল্ড

প্রদত্ত উদাহরণের বিচারে, 'প্রক্রিয়া' কী? হয় echoএবং >না পৃথক (ছোট বাস করতেন) প্রসেস? এবং echoআগে থাকা আউটপুট >কার্যকর করা হয় যেখানে ?

— oɔɯǝɹ

1

@ oɔɯǝɹ >হ'ল শেল পুনঃনির্দেশ। এটি একই রকম যদি প্রোগ্রামটি লেখার জন্য নামকৃত ফাইলটি খোলে এবং স্টাডআউটটি প্রতিস্থাপন করে যা শেলটি ঠিক কী করে।

— ড্যান ডি

7

আমার মনে হয় এটা আপনাকে দিতে ওএস দায়িত্ব fileধারণকারী Helloতা রাঙা বা না নির্বিশেষে।

— সালমান এ

1

যদি প্রোগ্রামটি মেশিন এ তে চলছে, এবং আপনি মেশিন বিতে ফাইলটি পড়ছেন, মেশিন এ এর ফাইল সিস্টেমটি নেটওয়ার্কের উপর মাউন্ট করা আছে, তবে আপনি নেটওয়ার্ক ফাইল সিস্টেমের ধরন এবং মাউন্ট সেটিংসের উপর নির্ভর করে একটি খালি ফাইলটি পড়া শেষ করতে পারেন। সুতরাং আপনি যে মাউন্ট জন্য ক্যাশে অক্ষম করতে চাইতে পারেন।

— পিটিএস

21

জড়িত বাফার / ক্যাশে একাধিক স্তর রয়েছে।

সিপিইউ ক্যাশে।

ডেটা বাইট বাই একসাথে রাখা হয়, এবং সিপিইউ ক্যাশে সংরক্ষণ করা হয়। যদি সিপিইউ ক্যাশে পূর্ণ থাকে এবং কিছুক্ষণের জন্য ডেটা অ্যাক্সেস না করা হয়, তবে আমাদের ডেটা সম্বলিত ব্লকটি মূল স্মৃতিতে লিখিত হতে পারে। এগুলি, বেশিরভাগ অংশে, অ্যাপ্লিকেশন প্রোগ্রামারদের থেকে গোপন।
প্রক্রিয়া বাফার।

প্রক্রিয়াটিতে কিছু মেমরি আলাদা করা আছে যেখানে ডেটা সংগ্রহ করা হয় তাই আমাদের ওএসকে যতটা সম্ভব অনুরোধ করা দরকার, কারণ এটি তুলনামূলকভাবে ব্যয়বহুল। প্রক্রিয়াটি এই বাফারগুলিতে ডেটা অনুলিপি করে, যা আবার সিপিইউ ক্যাশে সমর্থন করে, সুতরাং কোনও গ্যারান্টি নেই যে ডেটা মূল স্মৃতিতে অনুলিপি করা হয়েছে। অ্যাপ্লিকেশনটিতে এই বাফারগুলিকে স্পষ্টভাবে ফ্লাশ করা দরকার, উদাহরণস্বরূপ fclose (3) বা fsync (3) ব্যবহার করে। প্রক্রিয়াটি শেষ হওয়ার আগে প্রস্থান (3) ফাংশনটি এটিও করে, যখন _exit (2) ফাংশনটি করে না , তাই এই ফাংশনের জন্য ম্যানুয়াল পৃষ্ঠায় একটি বড় সতর্কতা রয়েছে কেবল তখনই আপনি যদি জানেন যে আপনি কী করছেন করছেন।
কার্নেল বাফার করে

তারপরে ডিস্কগুলিতে পাঠানোর জন্য প্রয়োজনীয় সংখ্যার সংখ্যা কমাতে ওএস তার নিজস্ব ক্যাশে রাখে। এই ক্যাশেটি বিশেষত কোনও প্রক্রিয়ার সাথে সম্পর্কিত নয়, সুতরাং সেখানে থাকা ডেটাগুলি এমন প্রক্রিয়াগুলির সাথে সম্পর্কিত হতে পারে যা ইতিমধ্যে শেষ হয়ে গেছে এবং যেহেতু সমস্ত অ্যাক্সেসগুলি এখানে চলে যায়, পরবর্তী প্রোগ্রামটি এখানে পৌঁছে গেলে ডেটা দেখতে পাবে। কার্নেল যখন ডিস্কগুলিতে এটি করার সময় হয় বা স্পষ্টভাবে জিজ্ঞাসা করা হয় তখন এই ডেটা লিখবে।
ড্রাইভ ক্যাশে

ডিস্কগুলি চালনা করে অ্যাক্সেসগুলিকে গতি বাড়ানোর জন্য একটি ক্যাশে রাখে। এগুলি মোটামুটি দ্রুত লেখা হয়, এবং ক্যাশেগুলিতে থাকা বাকী ডেটাগুলি লেখার জন্য এবং সেখানে সম্পূর্ণ হওয়ার পরে রিপোর্ট করার জন্য একটি কমান্ড রয়েছে যা ওএস শাটডাউন ব্যবহার করে কোনও তথ্য অলিখিতভাবে না ফেলে তা নিশ্চিত করার জন্য ব্যবহার করে।

আপনার অ্যাপ্লিকেশনটির জন্য, তথ্যটি কার্নেল বাফারগুলিতে নিবন্ধিত করার জন্য যথেষ্ট (আসল তথ্যগুলি এখনও এই সময়ে সিপিইউ ক্যাশে থাকতে পারে এবং মূল স্মৃতিতে লেখা নাও হতে পারে): "প্রতিধ্বনি" প্রক্রিয়াটি সমাপ্ত হয়, যা এর অর্থ হ'ল যে কোনও প্রক্রিয়াগত বাফার অবশ্যই ফ্লাশ হয়ে গেছে এবং ডেটা ওএসের কাছে হস্তান্তর করা হয়েছে এবং আপনি যখন নতুন প্রক্রিয়া শুরু করবেন তখন নিশ্চয়তা দেওয়া হয় যে ওএস জিজ্ঞাসা করলে একই তথ্য ফিরিয়ে দেবে।

— সাইমন রিখটার
সূত্র

7

সিপিইউ ক্যাচিং বিবেচনা করা আমার কাছে প্রাসঙ্গিক বলে মনে হয় না। এটি এখানে বিশদের একটি অপ্রয়োজনীয় স্তর। হার্ড ডিস্ক প্লাটার বা এসএসডি মেমরির কিছুটা দৈহিক পরিমাণ উপস্থাপন না করা অবধি যতক্ষণ না সমস্ত বিবরণ দেখা যায় তা এটিকে ফ্লিপ করার জন্য পরিবর্তন করা হয়।

— এমভিডব্লিউ

3

আসলে, সিপিইউ ক্যাশে মোটামুটি orthogonal।

— সাইমন রিখটার

2

এবং আরও গুরুত্বপূর্ণ বিষয়, সিপিইউ ক্যাশেটি কোরগুলির মধ্যে সুসংগত, যার কারণে এটি সম্পূর্ণ চিত্রের বাইরে। এক্স ৮86-এ, এটি ডিএমএর সাথেও সুসংগত (এবং x86 এর মোট-স্টোর-অর্ডার মেমরি-অর্ডারিং মোড রয়েছে), তাই মেমরি পড়তে পারে এমন যে কোনও কিছু মেমরি ক্রিয়াকলাপের বিশ্বব্যাপী সেই ঠিকানায় সঞ্চিত ডেটা দেখতে পাবে। (স্টোর সারি থেকে স্টোর-ফরওয়ার্ডিংয়ের কারণে, একটি সিপিইউ কোর বিশ্বব্যাপী দৃশ্যমান হওয়ার আগেই তার নিজস্ব স্টোরগুলি দেখতে পাবে)। ক্যাশে-সুসংহত ডিএমএ ছাড়াই নন-এক্স ৮ plat প্ল্যাটফর্মে, লিনাক্স কার্নেল নিশ্চিত করে যে এই ঠিকানাগুলিতে ডিএমএর আগে ক্যাশে ফ্লাশ হয়েছে।

— পিটার কর্ডেস

1

"এগুলি বেশিরভাগ ক্ষেত্রে অ্যাপ্লিকেশন প্রোগ্রামারদের থেকে গোপন।" কেন "বেশিরভাগ অংশের জন্য"? আমি এম্বেডড ডেভেলপার এবং বুট লোডার চলাকালীন (তাই "অ্যাপ্লিকেশন" নয়) আমি সিপিইউ ক্যাশে সম্পূর্ণ উপেক্ষা করি। আমি মনে করি না কোনও অ্যাপ্লিকেশন বিকাশকারী সিপিইউ ক্যাশের প্রভাব দ্বারা প্রভাবিত হতে পারে।

— স্যাম

1

@ সাম ক্যাশে অনুমানমূলক মৃত্যুদণ্ডের সাথে একসাথে মিস / হিটগুলি কিছু সিপিইউতে পড়ার অ্যাক্সেস বিধিনিষেধকে বাইপাস করতে শোষণ করা যেতে পারে। সম্ভবত এই উত্তরটি কি উল্লেখ করা হচ্ছে?

— জন ডিভোরাক

22

যদি অ্যাপ্লিকেশনটির কোনও অভ্যন্তরীণ ক্যাশে না থাকে, তবে পরিবর্তনগুলি তাত্ক্ষণিকভাবে ফাইলটিতে লেখা হবে। আপনার উদাহরণের জন্য একই। ফাইলটি স্মৃতিতে একটি লজিক্যাল সত্তা যা অবিলম্বে আপডেট করা হবে। ফাইলের পরবর্তী কোনও ক্রিয়াকলাপ প্রোগ্রাম দ্বারা পরিবর্তনগুলি দেখতে পাবে।

তবে এর অর্থ এই নয় যে পরিবর্তনটি দৈহিক ডিস্কে লেখা হয়েছিল to পরিবর্তনগুলি ওএস ফাইল সিস্টেম ক্যাশে বা হার্ডওয়্যার ক্যাশে স্থির থাকতে পারে। ফাইল সিস্টেম বাফারগুলি ফ্লাশ করতে, syncকমান্ডটি ব্যবহার করুন ।

কমান্ডটি প্রস্থান করার সাথে সাথেই আমি ফাইলটি পড়তে চাই, তবে আমি খালি ফাইলটি পড়তে চাই না।

আপনার এখানে কোনও ব্যবহারিক সমস্যায় পড়তে হবে না।

— mtak
সূত্র

1

"যদি অ্যাপ্লিকেশনটির কোনও অভ্যন্তরীণ ক্যাশে না থাকে" - এটি একটি খুব বড় "যদি": আই / ও লাইব্রেরি বাস্তবায়নের সিংহভাগই ডিফল্টরূপে বাফার স্টাডাউট ব্যবহার করে। এটি বলেছিল, উদাহরণস্বরূপ সি স্ট্যান্ডার্ড exitহ'ল স্ট্যান্ডআউট বাফারটি প্রস্থান করার পরে ফ্লাশ করা হবে (তবে কমপক্ষে স্পষ্টভাবে বলা না হলে সম্ভবত না )। অন্যান্য গ্রন্থাগার / ভাষা (যেমন জাভা!) কম গ্যারান্টি দেয়।

— কনরাড রুডল্ফ

তবে কী কেবল এটিকে পুনর্নির্দেশের আদিমতার মধ্যে সীমাবদ্ধ করে (যেমন, আমার প্রশ্নে আদেশটি)? এটা না অভ্যন্তরীণ ক্যাশে আছে, তাই না?

— এরিক

@ এরিক না, আপনার ভাল হওয়া উচিত।

— এমটাক

10

আমি এই উত্তরটি পেয়েছি কিনা তা নিশ্চিত নই। প্রশ্নটি "প্রক্রিয়াটি কখন প্রস্থান হয়" সম্পর্কে। অভ্যন্তরীণ লেখার ক্যাশেযুক্ত প্রতিটি অ্যাপ্লিকেশন প্রসেস প্রস্থান করার সময় ডিস্কে ফ্লাশ করবে, যদি এটি আগে না ঘটে। আইওউ, এই সমস্ত ক্যাশে এখানে কিছু আসে যায় না।

— এমসাল্টাররা 15'20

2

তদুপরি, একটি অভ্যন্তরীণ বাফার হয় প্রস্থান করার সময় ফ্লাশ করা হবে বা কেবল অস্তিত্ব থেকে বিবর্ণ হবে, তাই না? সুতরাং এমনকি অভ্যন্তরীণ বাফারগুলি ফ্লাশ না করলেও সামগ্রীটি পর্যবেক্ষণযোগ্য হবে না, যতক্ষণ অপেক্ষা করা হোক না কেন।

— ওয়ার্ল্ডসেন্ডার

21

কোনও প্রক্রিয়াটি বের হয়ে গেলে বাফারটি স্বয়ংক্রিয়ভাবে ডিস্কে ফ্লাশ হয়ে যাবে?

সাধারণভাবে উত্তরটি হ'ল না ।

এটি কমান্ডের উপর নির্ভর করে। হিসাবে অন্যান্য উত্তর উল্লেখ, যদি কমান্ড অভ্যন্তরীণভাবে Data Buffer নয়, সমস্ত ডেটা উপলব্ধ কমান্ড বন্ধ থাকবে।

কিন্তু, সব না হলেও স্ট্যান্ডার্ড ইনপুট / আউটপুট লাইব্রেরি না stdout- এ (কিছু পরিমাণে) ডিফল্টভাবে বাফার, এবং বাফার যখন আবেদন প্রচেষ্টা স্বয়ংক্রিয় অনিদ্রা তা কিছুটা ভিন্ন গ্যারান্টী দিতে।

সি গ্যারান্টি দেয় যে একটি সাধারণ প্রস্থান বাফারগুলি ফ্লাশ করবে । "সাধারণ প্রস্থান" এর অর্থ এটি exitবলা হয় - হয় স্পষ্টতই, বা ফিরে এসে main। যাইহোক, অস্বাভাবিক প্রস্থান এই কলটিকে অবরুদ্ধ করতে পারে (এবং তাই ফলস্বরূপ বাফারগুলি পিছনে ছেড়ে যান)।

এখানে একটি সাধারণ উদাহরণ:

#include <signal.h>
#include <stdio.h>

int main() {
    printf("test");
    raise(SIGABRT);
}

আপনি যদি এটি সঙ্কলন করেন এবং এটি সম্পাদন করেন, অগত্যা stdout এ লেখা testহবে না ।

অন্যান্য প্রোগ্রামিং ভাষা এমনকি তার চেয়ে কম নিশ্চয়তা দিতে: জাভা, উদাহরণস্বরূপ, আছে না প্রোগ্রাম পরিসমাপ্তি উপর স্বয়ংক্রিয় ফ্লাশ । যদি আউটপুট বাফারটিতে একটি নির্বিঘ্নিত লাইন থাকে তবে System.out.flush()এটি স্পষ্টভাবে বলা না হলে এটি হারিয়ে যেতে পারে ।

তাই বলা হয়, আপনার প্রশ্নের শরীর কিছু কিছুটা ভিন্ন জিজ্ঞেস করল: তথ্য ফাইল এসে পৌঁছায় যদি এ সব , এটা কমান্ড বন্ধ (অন্যান্য উত্তর বর্ণিত আদেশ সহকারে বিষয়) পর তাই অবিলম্বে করা উচিত।

— কনরাড রুডল্ফ
সূত্র

7

আমি যখন কোনও কমান্ড-লাইন সরঞ্জাম কোনও ফাইল এবং স্টাডআউট বা স্ট্ডারকে একটি ডিবাগ লগের মতো লিখতে থাকে তখন অস্বাভাবিক প্রস্থানও দেখেছি এবং ব্যবহারকারী মাথা ছাড়ার জন্য একটি পাইপ করেছেন বা কম লিখে 'কিউ' টাইপ করেছেন কম প্রস্থান করার জন্য। কমান্ড-লাইন সরঞ্জামটি SIGPIPE পরিচালনা না করলে ডিস্ক ফাইলটি সর্বদা পুরোপুরি ফ্লাশ হয় না।

— জ্যান লিংস

+1, তবে " কমান্ডটি সমাপ্ত হওয়ার সাথে সাথেই এটি করা উচিত " বেশ সঠিক নয়: প্রক্রিয়াটি শেষ হওয়ার আগে যে কোনও write()বা pwrite()সিস্টেম কল ঘটবে এবং ফাইলের পরিবর্তনগুলি দৃশ্যমান হওয়ার পরে become সুতরাং সর্বশেষ ফাইল পরিবর্তন প্রক্রিয়াটি সমাপ্তির আগে অবশ্যই , সর্বশেষতম সময়ে before আমি মনে করি এমনকি একটি ফাইল সহ, প্রক্রিয়া সমাপ্তি পর্যবেক্ষণ করার কোনও উপায় নেই যা ঘটতে চলেছে এমন সমস্ত ফাইল পরিবর্তন হওয়ার আগে ঘটবে। mmap(MAP_SHARED)

— পিটার কর্ডেস

9

আমি মনে করি যে কোনও প্রশ্নই এই সমস্যাটিকে যথেষ্টভাবে সমাধান করে না:

কমান্ডটি প্রস্থান করার সাথে সাথেই আমি ফাইলটি পড়তে চাই, তবে আমি খালি ফাইলটি পড়তে চাই না।

অন্যান্য উত্তরগুলি যেমন ব্যাখ্যা করে, প্রক্রিয়াটি স্বাভাবিকভাবে শেষ হওয়ার আগে একটি ভাল আচরণকারী প্রোগ্রামটি তার অভ্যন্তরীণ ফাইল বাফারগুলিকে ফ্লাশ করে । এরপরে অবিরাম স্টোরেজে লেখার আগে ডেটা কার্নেল বা হার্ডওয়্যার বাফারগুলিতে এখনও লম্বা হতে পারে। যাইহোক , লিনাক্সের ফাইল সিস্টেম শব্দার্থবিজ্ঞান গ্যারান্টি দেয় যে সমস্ত প্রক্রিয়া ফাইলের বিষয়বস্তু একইভাবে দেখতে পায় যেমন কার্নেল যেমন অভ্যন্তরীণ বাফার ^{1 অন্তর্ভুক্ত করে} ।

এটি সাধারণত ফাইল আইটেম প্রতি সর্বাধিক এক ইন-কার্নেল বাফার থাকার মাধ্যমে প্রয়োগ করা হয় এবং এই বাফারের মাধ্যমে সমস্ত ফাইল অ্যাক্সেসের প্রয়োজন হয়।

যদি কোনও প্রক্রিয়া কোনও ফাইল পড়ে, তবে অনুরোধ করা ফাইল অংশটি বর্তমানে বাফারে থাকলে কার্নেলটি প্রক্রিয়াটিতে বাফার সামগ্রী উপস্থাপন করবে; যদি এটি না হয়, কার্নেল অন্তর্নিহিত স্টোরেজ মিডিয়াম থেকে ডেটা আনবে এবং এটি বাফারের ভিতরে রাখবে, তারপরে আগের ধাপে ফিরে যাবে।
যদি কোনও প্রক্রিয়া কোনও ফাইলকে লিখতে থাকে তবে ডেটাটি প্রথমে সেই ফাইলটির জন্য ইন-কার্নেল বাফারের ভিতরে রাখা হয়। অবশেষে বাফার সামগ্রীগুলি স্টোরেজে ফ্লাশ করা হবে। মাঝামাঝি সময়ে পড়ার অ্যাক্সেস একই বাফার থেকে সন্তুষ্ট হয় (উপরে দেখুন)।

¹ কমপক্ষে নিয়মিত ফাইল, ডিরেক্টরি এবং প্রতীকী লিঙ্কগুলির জন্য। ফিফ এবং সকেটগুলি আলাদা বিষয় কারণ যেহেতু তাদের সামগ্রী কখনও অবিচ্ছিন্নভাবে সংরক্ষণ করা হয় না। নিয়মিত ফাইলগুলির কয়েকটি বিশেষ ক্ষেত্রে রয়েছে যার বিষয়বস্তুগুলি কে জিজ্ঞাসা করছে তার উপর নির্ভর করে; উদাহরণগুলি প্রোফস এবং সিএসএফ-এর ফাইল (মনে করুন /proc/selfযা প্রতীকী লিঙ্কটি পড়ার প্রক্রিয়া আইডির একটি প্রতীকী লিঙ্ক)।

— ডেভিড ফোস্টার
সূত্র

2

কড়া কথায় বলতে গেলে, এটি লিনাক্সের ফাইল সিস্টেম সিনটিক্স নয় যা এটির গ্যারান্টি দেয়, এটি পসিক্স শব্দার্থিক যা করে। বিশেষত, বিএসডি ম্যাকোস এবং উইন্ডোজের মতো ঠিক একই আচরণ করে (যদিও উইন্ডোজ পসিক্স শব্দার্থকে অনুসরণ করে এমন কয়েকটি ক্ষেত্রে এটি একটি)। এটি mmap()O_DIRECT এর সাথে কারও অদ্ভুত স্টাফও করছে না বলে ধরে নেয় , যা ডিস্ক এবং পৃষ্ঠা ক্যাশের মধ্যে জিনিসগুলির বাইরে-সিঙ্ক হওয়ার কারণ হতে পারে (তবে প্রক্রিয়াটি যে প্রক্রিয়াটি শেষ হবে সেই মুহুর্তটি সমাধান করবে)।

— অস্টিন হেমেলগার্ন

2

@ অস্টিনহেমলগার্ন: কঠোরভাবে বলতে গেলে আমরা উভয়ই ঠিক বলেছি যেহেতু লিনাক্স ইউনিক্স (সিস্টেম ভি) অ্যাপ্লিকেশনগুলিকে মাথায় রেখে নকশাকৃত করা হয়েছিল এবং পরে পসিক্সকে সমর্থন করার জন্য তৈরি করা হয়েছিল যা সিস্টেম ভি-তেও অনেক ধারণার ভিত্তি তৈরি করেছে

— ডেভিড ফোরস্টার

5

আপনার কমান্ডটি সি রানটাইম লাইব্রেরি ব্যবহার করে কোনও প্রোগ্রাম দ্বারা কার্যকর করা হয়েছে বলে ধরে নেওয়া, কোনও সময়ে এটি fcloseখোলা ফাইলটি বন্ধ করার জন্য অনুরোধ করা উচিত ।

fcloseসি ফাংশনের জন্য ম্যান পেজটি বলেছেন:

নোটস নোট করুন যে fclose () কেবল সি লাইব্রেরির দ্বারা সরবরাহকৃত ব্যবহারকারী স্পেস বাফারগুলিকে ফ্লাশ করে। ডেটা শারীরিকভাবে ডিস্কে ডেটা সংরক্ষণ করা হয়েছে তা নিশ্চিত করার জন্য কার্নেল বাফারগুলিকে খুব বেশি ফ্লাশ করা আবশ্যক, উদাহরণস্বরূপ, সিঙ্ক (2) বা fsync (2) দিয়ে।

এবং ম্যান পেজের fflushএকই নোট রয়েছে। ম্যান পেজটি closeবলেছেন:

একটি সফল নিকট গ্যারান্টি দেয় না যে ডেটা সাফল্যের সাথে ডিস্কে সংরক্ষণ করা হয়েছে, যেমন কার্নেল ডিফাররা লিখেছেন। স্ট্রিমটি বন্ধ হয়ে গেলে কোনও ফাইল সিস্টেমের পক্ষে বাফারগুলি ফ্লাশ করা সাধারণ নয়। আপনার যদি নিশ্চিত হওয়া দরকার যে ডেটা শারীরিকভাবে সঞ্চিত আছে তবে fsync (2) ব্যবহার করুন। (এটি এই মুহুর্তে ডিস্ক হার্ডওয়্যারের উপর নির্ভর করবে।)

মনে রাখবেন যে ড্রাইভে সিঙ্ক করা না থাকলেও ডেটা অন্যান্য প্রক্রিয়াগুলিতে উপলব্ধ। আপনার জন্য এটি ইতিমধ্যে যথেষ্ট ভাল।

আপনার যদি সন্দেহ হয় তবে একটি পরীক্ষা লিখুন।

— mvw
সূত্র

2

সি বা না, সমস্ত কিছুই / close()ফাইলের বর্ণনাকারী বন্ধ করার জন্য সিস্কেলটি ব্যবহার করে ।

— Attié

@ অট্টি: প্রস্থান করার আগে আপনার ফাইলের দরকার নেইclose (হ্যাকি প্রোগ্রামগুলিতে যা ত্রুটিগুলি পরীক্ষা করে না); কার্নেল এগুলি পরিষ্কার করে দেবে, closeআপনার প্রক্রিয়াটি মারা যাওয়ার পরে কার্যকরভাবে আপনাকে কল করবে। আপনার fcloseকোনও বাফারড স্টাডিও স্ট্রিমের দরকার নেই, তবে, বা প্রেরণ exit(3)সিস্টেমের সরাসরি কলের বিপরীতে লিবিকে আপনার জন্য এটি করতে দিন ।

— পিটার কর্ডেস

আপনার যদি সন্দেহ হয় তবে একটি পরীক্ষা লিখুন। এটি জাতিদের শর্তগুলি সনাক্ত করার জন্য খারাপ পরামর্শ। এক টুকরো হার্ডওয়ারে চলমান একটি কার্নেলের উপর পরীক্ষা করা আপনাকে বলতে পারে যে সেই সিস্টেমে আপনার পরীক্ষার দ্বারা প্রস্তুত সফ্টওয়্যার অবস্থার অধীনে রেসটি ঘটতে পারে না, বা এটি সনাক্ত করা খুব বিরল। তবে আচরণটি সমস্ত ফাইল সিস্টেম, কার্নেল এবং সমস্ত হার্ডওয়্যার (যেমন পাওয়ারপিসি) জুড়ে নিরাপদ থাকার কথা কিনা তা আপনাকে বলতে পারে না । অর্থাৎ আপনি যে গ্যারান্টিটির উপর নির্ভর করছেন তা বাস্তবায়ন বিশদ বা উদ্দেশ্যমূলক ভবিষ্যতের-প্রমাণ গ্যারান্টি কিনা তা আপনি বলতে পারবেন না! (এই ক্ষেত্রে এটি))

— পিটার কর্ডেস

এটা পরিস্থিতির উপর নির্ভর করে। কিছু লোক তার শেল স্ক্রিপ্টটি চালানোর চেষ্টা করছে এই পরামর্শের সাহায্যে। এটি আরও উন্নত তবে কম সম্ভাব্য পরিবেশগুলির জন্য সাধারণ সমাধান হিসাবে উদ্দিষ্ট নয়, যেমন কোনও ওএস কার্নেলের উপর কাজ করা একটি সফ্টওয়্যার ইঞ্জিনিয়ার, কিছু লোক লোক ইন্টেলের মাইক্রোকোড আপডেটে কাজ করে, বা কিছু গাল আইএসএসের জন্য কোনও সিস্টেমে কাজ করে।

— এমভিডাব্লু

3

আমি যখন কোনও ফাইলে কোনও কমান্ডের আউটপুট পুনঃনির্দেশ করি (উদাহরণস্বরূপ echo Hello > file) সেই ফাইলটি কি কমান্ডটি প্রস্থান করার সাথে সাথে এই জাতীয় ডেটা থাকার নিশ্চয়তা পাবে?

হ্যাঁ। শেল আউটপুট-ফাইলটি খুলবে এবং echoসরাসরি এতে আউটপুট দেয়। কমান্ডটি প্রস্থান করার পরে এটি সম্পন্ন হয়েছে।

অথবা কমান্ডটি প্রস্থান করে এবং ফাইলটিতে লেখা ডেটার মধ্যে এখনও খুব ছোট উইন্ডো রয়েছে?

ডেটাটি মিডিয়াতে ইতিমধ্যে রয়েছে কিনা তা অন্য কোনও বিষয়, যা কেবল তখনই তার জন্য গুরুত্বপূর্ণ যখন তার পরে কোনও হার্ডওয়্যার ব্যর্থতা দেখা দেয় বা আপনি মাউন্ট করা ফাইল সিস্টেমটি বাইপাস করে কিছু ফরেনসিক সফ্টওয়্যার দ্বারা লাইভ পার্টিশনটি পরীক্ষা করেন।

কমান্ডটি প্রস্থান করার সাথে সাথেই আমি ফাইলটি পড়তে চাই, তবে আমি খালি ফাইলটি পড়তে চাই না।

চিন্তা করবেন না, কার্নেলটি ফাইলটির একটি ভিউ রাখে, এটি কতবার খোলার থেকে আলাদা।

— Deduplicator
সূত্র

"কার্নেল কেবল ফাইলটির একটি দৃষ্টিভঙ্গি রাখে": এর জন্য একেবারেই সত্য নয় mmap(MAP_SHARED): এমএমএড অঞ্চলের স্টোরগুলি ফাইলের পড়ার সাথে সুসংগত নয় (সেই থ্রেড বা অন্যান্য প্রক্রিয়া দ্বারা)। এই কারণেই msync(2)রয়েছে। অন্ততপক্ষে মানব পৃষ্ঠাগুলি সে সম্পর্কে সতর্ক করে দিয়েছে; বাস্তবায়নের উপর নির্ভর করে লিনাক্স প্রকৃতপক্ষে পৃষ্ঠাগুলি থেকে শারীরিক পৃষ্ঠাগুলি মানচিত্র করতে পারে, এই ক্ষেত্রে আমি অনুমান করতে পারি যে এটি মূলত সুসংগত (মডিউল মেমোরি-ক্রম)। যাইহোক, এটি এখনও সব আগে ঘটে _exit(2)।

— পিটার কর্ডেস

2

একটি সাধারণ নিয়ম হিসাবে, কার্নেলের মালিকানাধীন যে কোনও ডেটা কর্নেল, পিরিয়ড দ্বারা রক্ষণাবেক্ষণ এবং পরিষ্কার করা হয়। যেমন ডেটা যেমন সিস্টেম কল দ্বারা কার্নেল মেমোরিতে স্থানান্তরিত ডেটা অন্তর্ভুক্ত write(2)।

তবে, যদি আপনার অ্যাপ্লিকেশন (যেমন সি লাইব্রেরি) এর উপরে বাফারিং করে , তবে কার্নেলের স্পষ্টতই কোনও ধারণা নেই এবং তাই এটি পরিষ্কার করার গ্যারান্টি দেয় না।

তদুপরি, আমি বিশ্বাস করি না যে পরিষ্কার-পরিচ্ছন্নতার জন্য কোনও সময়ের গ্যারান্টি রয়েছে — এটি সাধারণত "সেরা প্রচেষ্টা" (পরিবেশিত: "যখন আমার একটি সেকেন্ড থাকে") ভিত্তিতে সম্পাদিত হয়।

— Mehrdad
সূত্র

কোনও গ্যারান্টি আছে যে কোনও ক্লিনআপ / বাফার-ফ্লাশিং পিতামাতার প্রক্রিয়া waitpid()ফেরতের আগে ঘটবে , যদি পরিষ্কার-পরিচ্ছন্নতা কিছু ঘটে। অর্থাত্ অন্যান্য প্রক্রিয়াগুলি সেই প্রক্রিয়াটি দ্বারা করা কোনও ফাইল পরিবর্তন করার আগে প্রক্রিয়া সমাপ্তির সরাসরি পর্যবেক্ষণ করতে পারে না । (এনএফএস ফাইল টাইমস্ট্যাম্পগুলির মাধ্যমে অপ্রত্যক্ষ পর্যবেক্ষণের রায় দেওয়ার জন্য আমি "সরাসরি" বলেছিলাম, কারণ এনএফএস ক্যাচিং হোস্টগুলির মধ্যে পুরোপুরি সুসংগত নয়)

— পিটার কর্ডেস

@ পিটারকর্ডস: আমি মনে করি এটি "রক্ষণাবেক্ষণের" বিরোধিতা হিসাবে "ক্লিন আপ" দ্বারা আপনি কী বোঝাতে চেয়েছেন তা নির্ভর করে। আমার কাছে "রক্ষণাবেক্ষণ" হ'ল "একটি সুসংগত দৃষ্টিভঙ্গি সরবরাহ করা" (যার মধ্যে আপনার উল্লেখযোগ্য গ্যারান্টি রয়েছে) এবং "ক্লিন আপ" হ'ল "ফ্ল্যাশ টু ডিস্ক" যা আমি বিশ্বাস করি না একটি সময় গ্যারান্টি আছে।

— মেহরদাদ

ওহ আমি দেখতে পাচ্ছি, আপনি "ডিস্কে টু ডিস্ক" প্রশ্নের অংশটির উত্তর দিচ্ছেন যা ফাইলটি পড়ার পরে পরবর্তী প্রক্রিয়াগুলি কী দেখতে পাবে তার থেকে অপ্রাসঙ্গিক। "নোংরা আই / ও ক্যাশে / বাফার মেমরিটি পরিষ্কার করুন" অর্থে "ক্লিন আপ"। ঠিক আছে, আপনি fsync/ ব্যবহার না করা সময়সীমার কোনও নিশ্চয়তা নেই fdatasync, যদিও লিনাক্সে বাফার রাইট-ব্যাক /proc/sys/vm/dirty_writeback_centisecsএক সেকেন্ডের শততম পরে শুরু হবে (অন্য আই / ও ট্রাফিকের ফলে দেরি না হলে), এবং সেই প্রোফস ডিরেক্টরিতে থাকা অন্যান্য বিভিন্ন টিউনেবলগুলিও জিনিসগুলিকে প্রভাবিত করে (যেমন কীভাবে কোনও লিখিত-ব্যাক করার আগে বাফারগুলি বাড়ার জন্য বড়)।

— পিটার কর্ডেস

2

অথবা কমান্ডটি প্রস্থান করে এবং ফাইলটিতে লেখা ডেটার মধ্যে এখনও খুব ছোট উইন্ডো রয়েছে?

না, নেই।

কমান্ডটি প্রস্থান করার সাথে সাথেই আমি ফাইলটি পড়তে চাই, তবে আমি খালি ফাইলটি পড়তে চাই না।

কমান্ডটি প্রস্থান করার পরে আপনি ফাইলের চূড়ান্ত বিষয়বস্তু পড়তে পারবেন, আপনি কখনও খালি ফাইলটি পড়বেন না। (ইন সি এবং সি ++, ব্যবহার অপেক্ষার , waitpid , wait3 বা wait4 প্রস্থান প্রোগ্রামের জন্য অপেক্ষা করতে সিস্টেম কল, এবং শুধুমাত্র তারপর ফাইলটি পড়ার। আপনি যদি একটি শেল, অন্য প্রোগ্রামিং ল্যাঙ্গুয়েজ বা লাইব্রেরি (যেমন C লাইব্রেরি ব্যবহার করে থাকেন কল সিস্টেম বা জাভা প্রক্রিয়া শ্রেণি), এটি সম্ভবত ইতিমধ্যে এর মধ্যে অন্যতম এই সিস্টেম কল ব্যবহার করে))

হিসাবে অন্যান্য উত্তর এবং মন্তব্য উল্লেখ করেছেন, যদি আপনি প্রোগ্রামের কারণ যেমন অভ্যন্তরীণ আউটপুট বাফার অনিদ্রা (ছাড়া থেকে প্রস্থান করেছে প্রোগ্রামের প্রস্থান পরে একটি খালি ফাইল পড়া শেষ হতে পারে _exit , পরিত্যাগ বা একটি মারাত্মক সংকেত গ্রহণ, অথবা এটি কারণ একটি জাভা প্রোগ্রাম সাধারণত প্রস্থান করা)। তবে এই মুহুর্তে এগুলি করার জন্য আপনার কিছুই করার নেই: অখণ্ডিত ডেটা চিরতরে নষ্ট হয়ে যায়, অতিরিক্ত অপেক্ষা এটি পুনরুদ্ধার করে না।

— পয়েন্ট
সূত্র

0

হাঁ

সম্ভবত আরও অতিরিক্ত অতিরিক্ত উত্তর যুক্ত করার জন্য দুঃখিত, তবে বেশিরভাগই প্রশ্নের শিরোনামের লাল বর্ণের উপর ফোকাস বলে মনে হচ্ছে। তবে আমি যতদূর বলতে পারি, প্রশ্নটি মোটেও বাফারিংয়ের ক্ষেত্রে নয়, তবে এটি:

আমি যখন কোনও ফাইলে কোনও কমান্ডের আউটপুট পুনর্নির্দেশ করি (উদাহরণস্বরূপ, ইকো হ্যালো> ফাইল) সেই ফাইলটি কি কমান্ডটি প্রস্থান করার সাথে সাথে এই জাতীয় ডেটা থাকার নিশ্চয়তা পাবে?

হ্যাঁ, নিঃশর্তভাবে। ">" এর সাথে আপনি বর্ণনা করছেন এমন ">" এর ব্যবহার এবং "<", সেই পাইপ-ভিত্তিক প্রক্রিয়াকরণ মডেল যা ইউনিক্স এবং লিনাক্স ওয়ার্ল্ড ভারি ভিত্তিক। আপনি প্রতিটি লিনাক্স ইনস্টলেশনতে হাজার হাজার স্ক্রিপ্ট পুরোপুরি এই আচরণের উপর নির্ভর করে পাবেন।

এটি আপনার নকশা অনুযায়ী যেমন চান তেমন কাজ করে, এবং যদি কোনও রেসের শর্তের সামান্যতম সুযোগও পাওয়া যায় তবে এটি সম্ভবত কয়েক দশক আগে সংশোধন করা হত।

— AnoE
সূত্র

দুর্ভাগ্যক্রমে এটি অনাবশ্যক। উত্তরগুলির মধ্যে কেবল বেশিরভাগটি অ-উদ্বায়ী স্টোরেজটিতে ডেটা প্রতিশ্রুতি দেওয়ার লাল-হেরিংকে কেন্দ্র করে। দেখুন @ পয়েন্ট এর উত্তর ও সুস্পষ্ট বর্ণনার জন্য বিভিন্ন অন্যদের: ফাইল পরিমার্জন প্রস্থান আগে ঘটে, বা এ সব।

— পিটার কর্ডেস