কোনও লিখন শুরু হওয়ার পরে বা এটি শেষ হয়ে গেলে কি কোনও বিজ্ঞপ্তি ফায়ার করে দেয়?


12

একটি ext3 fs- র নিয়মিত ফাইলের মাধ্যমে যোগাযোগ করে দুটি প্রক্রিয়া, একজন পাঠক এবং লেখক কল্পনা করুন। পাঠকের ফাইলটিতে একটি ইনোটিফাই IN_MODIFYওয়াচ রয়েছে। লেখক একক write()কলটিতে ফাইলটিতে 1000 বাইট লেখেন । পাঠক ইনোটিফাই ইভেন্ট পান এবং ফাইলটিতে কল fstatকরে। পাঠক কী দেখেন?

  1. রিডার st_sizeফাইলটিতে অন্তত 1000 ফিরিয়ে নেবে এমন কোনও গ্যারান্টি আছে কি ? আমার পরীক্ষাগুলি থেকে, মনে হয় না।

  2. রিডার আসলে read()1000 বাইট করতে পারে এমন কোন গ্যারান্টি আছে ?

এটি গুরুতরভাবে I / O বাউন্ড বাক্সে ঘটছে। উদাহরণস্বরূপ, sarপ্রায় 1 সেকেন্ডের জন্য অপেক্ষা করা সময়গুলি দেখায়। আমার ক্ষেত্রে পাঠক কল করার আগে ইনোটিফাই ইভেন্টটি statপাওয়া এবং খুব ছোট ফলাফল পাওয়ার পরে 10 সেকেন্ডের জন্য অপেক্ষা করছে ।

আমি যা আশা করেছিলাম তা ছিল ফাইল প্রস্তুত না হওয়া পর্যন্ত inotif ইভেন্ট বিতরণ করা হবে না। আমার সন্দেহজনকভাবে ঘটছে যা হ'ল write()রাইটারে কল করার সময় ইনোটিফাই ইভেন্টটি আগুন জ্বলে ওঠে এবং যখনই এটি প্রস্তুত হওয়ার ঘটনা ঘটে তখন সিস্টেমটি অন্যান্য প্রসেসের কাছে ডেটা প্রকৃতপক্ষে পাওয়া যায়। এই ক্ষেত্রে, 10 সেকেন্ড পর্যাপ্ত সময় নয়।

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

অবশেষে - এই আচরণটি দেওয়া, inotify এর বিন্দুটি কী? আপনি তথ্যটি উপলব্ধ না হওয়া অবধি ইভেন্টটি পাওয়ার পরেও ফাইল / ডিরেক্টরিটি পোলিংয়ে আপনি কমিয়ে দিয়েছেন। পাশাপাশি এটি করাও যেতে পারে এবং inotify সম্পর্কে ভুলে যান।

*** সম্পাদনা ** * * ঠিক আছে, প্রায়শই ঘটে যায়, আমি যে আচরণটি দেখছি তা বাস্তবে অর্থবোধ করে, এখন আমি বুঝতে পারি যে আমি আসলে কী করছি। ^: _ ^

ফাইলটি যে ডিরেক্টরিটিতে থাকে সেটিতে আমি আসলে একটি IN_CREATE ইভেন্টের প্রতিক্রিয়া জানাচ্ছি So সুতরাং আমি প্রকৃতপক্ষে () 'ফাইলটি তৈরির প্রতিক্রিয়া হিসাবে ফাইলটি ইনএনএমডি ইভেন্ট নয়, যা পরে আসতে পারে।

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


আপনি কোনও ফাইলের পরিবর্তে পাইপ ব্যবহার করতে পারেন। Man mknod
daniel kullmann

দুটি প্রক্রিয়াটির মধ্যে একাধিক-টেরাবাইট বাফার রাখতে আমাদের একটি নিয়মিত ফাইল ব্যবহার করতে হবে। রিবুট জুড়ে বাফারে ডেটা সংরক্ষণ করার জন্য।
টড ফ্রি

উত্তর:


5

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

ভুল হতে পারে এমন জিনিসগুলির জন্য পরীক্ষা করুন:

  • আগের পাঠক হতে পারে পাঠক পুরানো বিজ্ঞপ্তি পাচ্ছেন।
  • পাঠক যদি কল করে statএবং তারপরে কল readবা তদ্বিপরীত হয় তবে এর মধ্যে কিছু ঘটতে পারে। আপনি যদি ফাইলটিতে সংযোজন চালিয়ে যান, statপ্রথমে কল করে গ্যারান্টি দেয় যে আপনি এতদূর পড়তে সক্ষম হবেন তবে পাঠক কল করার সময় দিয়ে আরও ডেটা লেখা হয়েছিল read, যদিও এটি এখনও ইনোটিফাই বিজ্ঞপ্তি না পেয়েছে।
  • কেবল লেখক কল করার writeঅর্থ এই নয় যে কার্নেলটি অনুরোধ করা অক্ষরের সংখ্যাটি লিখবে। খুব কম পরিস্থিতি রয়েছে যেখানে পারমাণবিক লেখাগুলি যে কোনও আকারের গ্যারান্টিযুক্ত। প্রতিটি writeকলের গ্যারান্টিযুক্ত পারমাণবিক, যাইহোক: কোনও কোনও সময়ে ডেটা এখনও লেখা হয় নি, এবং তারপরে হঠাৎ এন বাইটগুলি লেখা হয়েছে, যেখানে এনwrite কলটির রিটার্ন মান । আপনি যদি আংশিক-লিখিত ফাইলটি পর্যবেক্ষণ করেন তবে এর অর্থ writeএটির আকারের যুক্তির চেয়ে কম ফিরে এসেছে।

যা চলছে তা তদন্তের দরকারী সরঞ্জামগুলির মধ্যে রয়েছে:

  • strace -tt
  • নিরীক্ষিত সাবসিস্টেম

ধারণাগুলি জন্য আপনাকে ধন্যবাদ। আমি সবেমাত্র কোডটি পর্যালোচনা করেছি, এবং আমি আসলে ত্রুটি মামলার জন্য লেখার থেকে ফেরতের মান হিসাবে -1 অনুসন্ধান করছি। সুতরাং, এটি হতে পারে যে আমি লেখার থেকে রিটার্নের মান পাচ্ছি না এটি নির্দেশ করে যে সমস্ত ডেটা লেখা ছিল। তবুও, আমি যখন ফাইলটি ফ্যাক্টের পরে দেখি তখন আমি জানি যে "1000" বাইটগুলি সমস্তই সত্যই লিখিত ছিল, কারণ ফাইলটি ভাল আকারে রয়েছে, অর্থাত এটি সম্পূর্ণ, সুসংগত রেকর্ড সমন্বিত। সুতরাং প্রথম রেকর্ডটি আংশিকভাবে লেখা হচ্ছে না।
টড ফ্রি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.