কোনও ফাইল সন্নিবেশ সিস্টেল কেন নেই


11

আমার বোধগম্যতার জন্য, ফাইলগুলি পরিচালনা করার জন্য লিনাক্সে কেবলমাত্র sys_writyscall রয়েছে, যা ফাইলের বিষয়বস্তুকে ওভাররাইট করে (বা শেষে থাকলে এটি প্রসারিত করে)।

লিনাক্সে ফাইলগুলিতে সামগ্রী contentোকানো বা মুছে ফেলার জন্য কেন কোনও স্কাইল নেই?

যেহেতু সমস্ত বর্তমান ফাইল সিস্টেমে ফাইলটিকে অবিচ্ছিন্ন মেমরি ব্লকের মধ্যে সঞ্চয় করার প্রয়োজন নেই, একটি দক্ষ বাস্তবায়ন সম্ভব should (ফাইলগুলি খণ্ডিত হয়ে যাবে))

"লিখিত অনুলিপি" বা "স্বচ্ছ ফাইল সংক্ষেপণ" হিসাবে ফাইল সিস্টেমের বৈশিষ্ট্যগুলির সাথে, সামগ্রী সন্নিবেশ করার বর্তমান উপায়টি খুব অকার্যকর বলে মনে হচ্ছে।


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

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

1
@ মিউহ ওপেনভিএমএস এখনও আরএমএসের মাধ্যমে (রেকর্ড পরিচালনা পরিষেবা) করে।
রনজহান

1
ইউএনআইএক্স ফাইল সিস্টেমের মধ্যে রেকর্ড পরিচালনা ব্যবস্থা সরবরাহ থেকে দূরে সরানো শুরু করে।
ব্যবহারকারী 207421

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

উত্তর:


22

সাম্প্রতিক লিনাক্স সিস্টেমে যা বাস্তবে সম্ভব তবে ব্লক (বেশিরভাগ সময় 4096) সহ, বাইট গ্রানুলারিটি নয়, এবং কেবলমাত্র কিছু ফাইল সিস্টেমে (ext4 এবং xfs)।

ম্যানপেজ থেকে উদ্ধৃতি fallocate(2):

int fallocate(int fd, int mode, off_t offset, off_t len);

[...]

ফাইল স্পেস ভেঙে যাচ্ছে

FALLOC_FL_COLLAPSE_RANGEফ্ল্যাগটি নির্দিষ্ট করে (লিনাক্স ৩.১৫ থেকে পাওয়া যায়) modeকোনও গর্ত ছাড়াই কোনও ফাইল থেকে বাইট পরিসর সরিয়ে দেয়। ধস করতে হবে বাইট সীমাটি শুরু হয় offsetএবং len বাইটগুলির জন্য অবিরত থাকে । ক্রিয়াকলাপটি শেষ হওয়ার পরে, লোকেশন থেকে শুরু হওয়া ফাইলের বিষয়বস্তুগুলি offset+lenলোকেশনটিতে সংযোজন করা offsetহবে এবং ফাইলটি আরও lenছোট হবে।

[...]

ফাইল স্পেস বাড়ছে

FALLOC_FL_INSERT_RANGEফ্ল্যাগ নির্দিষ্ট করে (লিনাক্স ৪.১ থেকে উপলব্ধ) modeকোনও বিদ্যমান তথ্য ওভাররাইট না করে ফাইল আকারের মধ্যে একটি গর্ত in ুকিয়ে ফাইলের স্থান বাড়ায়। গর্তটি শুরু হবে offsetএবং lenবাইটগুলির জন্য অবিরত থাকবে । ফাইলের অভ্যন্তরে গর্ত সন্নিবেশ করার সময়, ফাইলের সামগ্রীগুলি শুরু হয়ে বাইট offsetদ্বারা byর্ধ্বমুখী (অর্থাত্ একটি উচ্চতর ফাইলের অফসেটে) স্থানান্তরিত হবে len। কোনও ফাইলের অভ্যন্তরে একটি গর্ত োকানো ফাইলের আকার lenবাইট দ্বারা বৃদ্ধি করে ।


1
"তবে ব্লক (4096) সহ, বাইট গ্রানুলারিটি নয়" - 4KiB ব্লকগুলি এক্সট 4 এ খুব সাধারণ, তবে এটির নিশ্চয়তা নেই। Ext4 1KiB, 2KiB এবং 4KiB ব্লক মাপ সমর্থন করে ; এবং আমি ext2 দিন থেকে মনে করি যে আলফা প্রসেসরের উপর, 8KiB পাশাপাশি সমর্থিত হয়েছিল। আপনি কেবল 4KiB ব্লক ধরে নিতে পারবেন না, আমি ভয় করি।
মার্সেলেম

1
4 কে (যা পূর্বনির্ধারিত) 1k এবং 2k এর একাধিক, সুতরাং 4k এক্সট 4 সহ ধরে নিয়ে কোনও সমস্যা নেই। যদিও xfs 4k এও ডিফল্ট হবে, এটি 4k এর চেয়ে বড় বিএসকে সমর্থন করবে - k৪ কে পর্যন্ত, তবে আমি কেবল একটি এফএস তৈরি করতে সক্ষম হয়েছি - এটির মাউন্ট করা কোনও ENOSYS ছাড়াই ব্যর্থ হয়। এবং যাইহোক, আপনি কিছু অনুমান করতে পারবেন না - এই বৈশিষ্ট্যটি সমস্ত fs- তে সমর্থিত নয়, তাই কেবল ব্লক = 4096 বলা ভাল, তাই পাঠকটিকে কিছুটা ভাসিয়ে দেওয়া এবং মানুষকে কিছু দেওয়ার সুযোগ না দিয়ে অনুপাতের কিছুটা ধারণা থাকতে পারে, বা আরও খারাপ যে এটি 512 বাইট বা কোনওভাবে ভিএম পৃষ্ঠার আকারের সাথে সম্পর্কিত।
মশবী

আপনি সম্পাদনার পরে (যেখানে আপনি এটি সাধারণত 4KiB বলে থাকেন), আমি পুরোপুরি সম্মত! আমার সমস্যাটি হ'ল এর আগে এটি সহজেই "ব্লকগুলি সর্বদা 4KiB" হিসাবে পড়েছিল যা লোকেরা এই ধারণাটি তৈরি করতে এবং বগী কোডটি লেখার কারণ হতে পারে।
মার্সেলেম

9

যেহেতু সমস্ত বর্তমান ফাইল সিস্টেমে ফাইলটিকে অবিচ্ছিন্ন মেমরি ব্লকের মধ্যে সঞ্চয় করার প্রয়োজন নেই,

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

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

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