অনুপস্থিত ইভেন্টগুলি (.git ডিরেক্টরিতে) অনুপস্থিত

11

আমি ইনোটিফাই ইভেন্টগুলি (যেমনটি ঘটে, পাইথন থেকে, লাইবিকে কল করে) পরিবর্তনের জন্য ফাইলগুলি দেখছি।

একটি চলাকালীন কিছু ফাইলের জন্য git clone, আমি কিছু অদ্ভুত দেখি: আমি একটি IN_CREATEইভেন্ট দেখি এবং lsএই ফাইলের মধ্যে সামগ্রী রয়েছে তবে আমি কখনও দেখি না IN_MODIFYবা করি IN_CLOSE_WRITE। আমি IN_CLOSE_WRITEফাইলগুলিতে প্রতিক্রিয়া জানাতে চাইছি কারণ এটি আমার সমস্যা সৃষ্টি করছে : বিশেষত ফাইল সামগ্রীগুলির একটি আপলোড শুরু করার জন্য।

অদ্ভুতভাবে আচরণ করা ফাইলগুলি .git/objects/packডিরেক্টরিতে থাকে এবং সেগুলি শেষ হয় .packবা .idx। গিট তৈরি করা অন্যান্য ফাইলগুলির আরও নিয়মিত IN_CREATE-> IN_MODIFY-> IN_CLOSE_WRITEচেইন থাকে (আমি IN_OPENইভেন্টগুলির জন্য দেখছি না )।

এটি ম্যাকোসে ডকারের অভ্যন্তরে রয়েছে তবে আমি লিনাক্সের ডকরে একই সিস্টেমের রিমোট প্রমাণ পেয়েছি, সুতরাং আমার সন্দেহ ম্যাকোস দিকটি প্রাসঙ্গিক নয়। যদি পর্যবেক্ষক এবং আমি এই দেখছি git cloneরয়েছে একই Docker ধারক।

আমার প্রশ্নগুলো:

  • এই ফাইলগুলিতে এই ইভেন্টগুলি কেন অনুপস্থিত?

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

সম্পাদনা করুন: https://developer.ibm.com/tutorials/l-inotify/ পড়া দেখে মনে হচ্ছে যা আমি দেখছি তার সাথে সামঞ্জস্যপূর্ণ

  • নামের মতো একটি পৃথক অস্থায়ী ফাইল tmp_pack_hBV4Alzতৈরি করা, সংশোধিত এবং, বন্ধ করা;
  • চূড়ান্ত নাম সহ এই ফাইলটিতে একটি হার্ড লিঙ্ক তৈরি করা হয়েছে .pack;
  • আসল tmp_pack_hBV4Alzনামটি মুছে ফেলা হয়েছে।

আমি মনে করি যে আমার সমস্যা, যা ফাইলগুলি আপলোড করার জন্য ট্রিগার হিসাবে ইনোটিফাই ব্যবহার করার চেষ্টা করছে, তারপরে .packফাইলটি অন্য কোনও ফাইলে একটি হার্ড লিঙ্ক, এবং এই ক্ষেত্রে আপলোড হচ্ছে তা লক্ষণীয়তা হ্রাস পাবে ?

linux  git  docker  libc  inotify 
— মিশাল চেরেমজা
সূত্র
উত্তরটি এখানে কোথাও হতে পারে ...
— চোরোবা
@ চোরোবা আপনারা ঠিক বলেছেন ... আমি এমএমএপের অনেকগুলি উল্লেখ দেখতে পেয়েছি এবং ইনোটিফাই এমএমএপি ফাইলগুলিতে অ্যাক্সেসের রিপোর্ট করে না
— মিশাল চেরেমজা
1
বিটিডব্লিউ আপনি যে মূল সমস্যাটি সমাধান করার চেষ্টা করছেন তা কী (ইনোটাইফাই সহ)? আরও কিছু শক্তিশালী সমাধান থাকতে পারে যে গিট প্রক্রিয়াটি একটি সংগ্রহস্থলটি কী করছে / করেছে তা দ্বিতীয়-অনুমান করার চেষ্টা করছে?
— কোস্টিক্স
@kostix এই অংশ github.com/uktrade/mobius3 , ডেস্কটপ AWS Fargate মধ্যে JupyterLab বা RStudio চলমান, এবং এস 3 থেকে পাত্রে থেকে ব্যবহারকারীদের হোম ফোল্ডার সিঙ্ক, এবং যারা বাড়িতে ফোল্ডারে .git ফোল্ডার থাকতে পারে। আমি জানি যে ইনোটিফাই সমাধানটি কখনই "দৃust়-দৃust়" হতে পারে না ... তবে আমি আশা করি এটি "যথেষ্ট শক্তিশালী" হতে পারে।
— মিশাল চেরেমজা
1
@ টিঙ্ক দেখে মনে হচ্ছে গ্রহণযোগ্য উত্তরটি লিনাক্স কার্নেলের কোনও প্যাচ? এটি আমার পক্ষে সন্দেহজনকভাবে কাজ করবে তবে ফার্গেটে আমার ক্ষেত্রে আমার নিয়ন্ত্রণ নেই don't (এবং আমি স্বীকার করি যে দীর্ঘমেয়াদে প্যাচ করা কার্নেলের উপর নির্ভর করে আমার কিছুটা পরিণতি হওয়ার
— আশঙ্কাও রয়েছে

উত্তর:

5

আপনার প্রশ্নের উত্তর আলাদাভাবে gitলিনাক্স 4.19.95 এ 2.24.1 এর জন্য :

  • এই ফাইলগুলিতে এই ইভেন্টগুলি কেন অনুপস্থিত?

আপনি IN_MODIFY/ IN_CLOSE_WRITEইভেন্টগুলি দেখেন না কারণ git cloneসর্বদা .git/objectsডিরেক্টরিগুলির আওতায় থাকা ফাইলগুলির জন্য হার্ড লিঙ্কগুলি ব্যবহার করার চেষ্টা করবে । নেটওয়ার্কে বা ফাইল সিস্টেমের সীমানা জুড়ে ক্লোনিং করার সময়, এই ইভেন্টগুলি আবার প্রদর্শিত হবে।

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

হার্ড লিঙ্কগুলির পরিবর্তনটি ধরতে আপনাকে ইনোটিফাই CREATEইভেন্টের জন্য একটি হ্যান্ডলার স্থাপন করতে হবে যা এই লিঙ্কগুলিকে অনুসরণ করে এবং ট্র্যাক করে। দয়া করে নোট করুন যে একটি সরল CREATEঅর্থ এর অর্থও বোঝাতে পারে যে নোম্পটি ফাইল তৈরি হয়েছিল। তারপরে, যে কোনও ফাইলের উপর IN_MODIFY/ এ IN_CLOSE_WRITEআপনাকে সমস্ত লিঙ্কযুক্ত ফাইলগুলিতে একই ক্রিয়াটি ট্রিগার করতে হবে। স্পষ্টতই আপনাকে DELETEইভেন্টের সেই সম্পর্কটিও সরিয়ে ফেলতে হবে ।

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

সংশোধন

চেক করার পর gitঘনিষ্ঠভাবে সোর্স কোড এবং চলমান gitসঙ্গে strace, আমি দেখেছি যে gitকরে ব্যবহার মেমরির ম্যাপ ফাইল, কিন্তু বেশিরভাগই বিষয়বস্তু পড়ার জন্য। এর ব্যবহার দেখুন xmmapযা সর্বদা PROT_READকেবলমাত্র সাথে কল করা হয়। । অতএব নিচে আমার আগের উত্তর না সঠিক উত্তর। তথাপি তথ্যের উদ্দেশ্যে আমি এখনও এটি এখানে রাখতে চাই:

  • তোমাকে দেখছি না IN_MODIFYঘটনা কারণ packfile.cব্যবহারসমূহ mmapফাইল অ্যাক্সেস এবং inotifyজন্য পরিবর্তন প্রতিবেদন নেই mmapইডি ফাইল।

    ইনোটিফায় ম্যানপেজ থেকে :

    ইনোটাইফাই এপিআই এমএমএপ (2), ম্যানসিঙ্ক (2), এবং মুনম্যাপ (2) এর কারণে ঘটতে পারে এমন ফাইল অ্যাক্সেস এবং পরিবর্তনগুলির প্রতিবেদন করে না।

— Ente
সূত্র
আমার পরিবর্তনগুলি সনাক্তকরণ প্রক্রিয়া নির্ভর করে IN_CLOSE_WRITE, যা আমি মনে করি যে ব্যবহার করার জন্য লেখা একটি ফাইল বন্ধ করার পরে এখনও ট্রিগার হতে পারে mmap, কারণ ফাইলটি একটি রাইটিং মোডে খোলা হত?
— মিশাল চেরেমজা
আমাকে এটি তদন্ত করতে হবে, তবে আমি সন্দেহ করব যে মেমরি ম্যাপ করা ফাইল কোনও প্রকার ইভেন্টকে মোটেই ট্রিগার করে না। বেশিরভাগ বর্ধিত ইভেন্টগুলি ফাইল বর্ণনাকারীর রাজ্যের সাথে সংযুক্ত থাকে তবে আপনি যখন mmapকোনও ফাইল জিনিসগুলি কিছুটা অর্ডার থেকে বেরিয়ে আসতে পারেন। উদাহরণস্বরূপ, আপনি যখন মেমরিতে ফাইল ম্যাপ করেছেন তখন আপনি একটি বন্ধ ফাইল বর্ণনাকারীর কাছে লিখতে পারেন।
— এন্টে
স্ক্র্যাচ করুন যে, আমি কেবল এই উদাহরণটি প্রয়োগের পরীক্ষা করেছি এবং আমি CLOSE_WRITE_CLOSEএমনকি closeএবং munmapশেষে অপসারণ করলেও আমি একটি পাই । প্রকৃত গিট বাস্তবায়নের জন্য আরও গভীর খনন করতে হবে ..
— এন্টে
হুম আমি আপনার সমস্যা পুনরুত্পাদন করতে কিছুটা লড়াই করছি। inotifywaitএবং git clone(2.24.1) এর সাথে আমার পরীক্ষায় আমি ফাইলগুলির জন্য একটি OPEN-> পাই get আপনি কি কোনও হ্যান্ডলার স্থাপন করতে ভুলে গেছেন ? দ্রষ্টব্য: আপনি একটি পাবেন কারণ সমস্ত লেখাগুলি ম্যাপযুক্ত মেমরির মাধ্যমে ঘটেছিল। CLOSE_NOWRITE,CLOSE*.idxCLOSE_NOWRITE,CLOSE*NOWRITE*
— এঞ্জ্রে
হ্যাঁ, এখানে রয়েছে CLOSE_NOWRITE: সমস্যাটি আমি দেখতে পাচ্ছি না IN_CLOSE_WRITEএবং আমি একটি আপলোড ট্রিগার করতে "পরিবর্তন" ফাইলটিতে প্রতিক্রিয়া জানাতে চাই, তবে ফাইলটি "রিডস" উপেক্ষা করুন। দ্রষ্টব্য, আমি আসলেই এখনই মনে করি এমএমএপ + ইনোটাইফাই সীমাবদ্ধতাটি একটি লাল-হার্ভিংয়ের কিছুটা। আমি মনে করি যে সমস্যাটি হ'ল প্রাথমিকভাবে .pack/ .idxফাইলগুলি অন্য কোনও ফাইলে হার্ড লিঙ্ক হিসাবে তৈরি করা হয়েছিল, এবং তাই কেবল ট্রিগার IN_CREATE(এবং OPEN-> CLOSE_NOWRITEপরে ঘটে যখন গিটটি আসলে ফাইলগুলি পড়তে থাকে)।
— মিশাল চেরেমজা
2

আমি অনুমান করতে পারি যে গিট বেশিরভাগ সময় পরমাণু ফাইল আপডেট ব্যবহার করে যা এইভাবে করা হয়:

  1. কোনও ফাইলের বিষয়বস্তু মেমোরিতে পড়ে (এবং সংশোধিত) হয়।
  2. পরিবর্তিত সামগ্রীগুলি পৃথক ফাইলে লিখিত হয় (সাধারণত মূল ডিরেক্টরি হিসাবে একই ডিরেক্টরিতে থাকে এবং একটি এলোমেলো ( mktempস্টাইল) নাম থাকে।
  3. তারপরে নতুন ফাইলটি rename(2)মূল ফাইলটির উপর দিয়ে ডি-ডি করা হবে; এই অপারেশনটি গ্যারান্টি দেয় যে ফাইলটির নাম ব্যবহার করে খোলার চেষ্টা করা প্রতিটি পর্যবেক্ষক পুরানো সামগ্রী বা নতুনটি পাবে।

এই জাতীয় আপডেটগুলি ইভেন্ট inotify(7)হিসাবে দেখা হয় moved_to- যেহেতু কোনও ডিরেক্টরি ডিরেক্টরিতে একটি ফাইল "পুনরায় প্রদর্শিত হয়"।

— kostix
সূত্র
আহ কিছু ফাইলের জন্য আমার মনে হয় এটি এটি করে: আমি বিভিন্ন IN_MOVED_FROMএবং IN_MOVED_TOইভেন্টগুলি দেখি । যাইহোক, আমি ফাইল .packএবং .idxফাইলগুলির জন্য এটি ঘটতে দেখছি না
— মিশাল চেরেমজা
প্যাক ফাইলগুলি বিশাল হতে পারে (বেশ কয়েকটি গিগাবাইট, কমপক্ষে 2GiB অবধি, আমি বিলিভ); পারমাণবিক আপডেট ব্যবহার করে তাদের চালিত করা স্টোরেজ স্পেসে নিষিদ্ধ হতে পারে, তাই অন্য কোনও কৌশল ব্যবহার করে সেগুলি আপডেট করা হতে পারে।
— ডিসেম্বর
2

এই গৃহীত উত্তরের ভিত্তিতে আমি ধরে নিয়েছি যে প্রোটোকল ব্যবহৃত হচ্ছে তার উপর ভিত্তি করে ইভেন্টগুলিতে কিছুটা পার্থক্য থাকতে পারে (যেমন এসএসএস বা https)।

--no-hardlinksবিকল্পটি দিয়ে স্থানীয় ফাইল সিস্টেম থেকে ক্লোনিং পর্যবেক্ষণ করার সময় আপনি কি একই আচরণ লক্ষ্য করেন ?

$ git clone git@github.com:user/repo.git
# set up watcher for new dir
$ git clone --no-hardlinks repo new-repo

একটি লিনাক্স এবং ম্যাক হোস্ট উভয় ক্ষেত্রেই এই পরীক্ষা চালানোর বিষয়ে আপনার পর্যবেক্ষণ আচরণটি সম্ভবত এই উন্মুক্ত সমস্যাটির কারণটি https://github.com/docker/for-mac/issues/896 হ্রাস করে তবে কেবল যুক্ত করা যুক্ত করে।

— dwrecked
সূত্র
2

আরেকটি সম্ভাবনা রয়েছে (মানুষের অবিচ্ছিন্ন থেকে):

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

এবং git cloneভারী ইভেন্ট প্রবাহ উত্পন্ন করতে পারে এমন সময় এটি ঘটতে পারে।

কীভাবে এড়ানো যায়:

  1. পঠন বাফার বৃদ্ধি করুন, fcntl (F_SETPIPE_SZ) চেষ্টা করুন (এই পদ্ধতির অনুমান, আমি কখনও চেষ্টা করিনি)।
  2. ডেডিকেটেড থ্রেডে ইভেন্টগুলি বড় বাফারে পড়ুন, ইভেন্টগুলি অন্য থ্রেডে প্রক্রিয়া করুন।
— ইউরি নেভিনিতসিন
সূত্র
2

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

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

— donjuedo
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.