একটি বিশাল ফোল্ডারটির নামকরণ: এটি ঝুঁকিপূর্ণ?


19

mvকমান্ড সহ 180 গিগাবাইট সহ ফোল্ডারটির নামকরণ করা কি ঝুঁকিপূর্ণ ?

আমাদের একটি ফোল্ডার /dataরয়েছে যাতে 180 গিগাবাইট রয়েছে।

কমান্ড দিয়ে আমরা /dataফোল্ডারটির নাম পরিবর্তন করতে চাই ।/BD_FILESmv

এটি করা কি নিরাপদ?


14
কেন এবং কীভাবে এটি ঝুঁকিপূর্ণ হওয়া উচিত? আপনি যদি অনিশ্চিত mvহন তবে -iবিকল্পটি দিয়ে কল করুন ।
ডেজার্ট

5
আপনার পরিবেশে এমন কিছু আছে যা আপনাকে ভাবতে পরিচালিত করে যে এটি ঝুঁকিপূর্ণ হতে পারে?
জেফ স্ক্যালার হলেন

2
আপনি কী বোঝাতে চেয়েছেন যে এই কাজটি এবং নিজে থেকেই এই সমস্যাটি তৈরি করতে পারে এমন ঝুঁকি রয়েছে বা সমস্যাযুক্ত প্রভাব থাকতে পারে এমন ঝুঁকি রয়েছে কিনা? আপনার যদি এমন কোনও প্রোগ্রাম থাকে যা সেখানে / ডেটা ফোল্ডার হওয়ার প্রত্যাশা করে থাকে তবে এর নামকরণ করা সমস্যার কারণ হতে পারে।
সংগৃহীত

3
পার্শ্ব-নোট: আপনার কাছে যাচাই করা ব্যাকআপ থাকলে প্রায় সবকিছুই নিরাপদ। কিছুই না থাকলে যতটা নিরাপদ তা হওয়া উচিত নয়। অন্য কথায়: "এটি কি নিরাপদ" জিজ্ঞাসা করার সময় আপনার প্রথম চিন্তাটি হওয়া উচিত "আমি কি আমার ব্যাকআপগুলি যাচাই করেছি?"
রেডগ্রিটিব্রিক

2
আমার অর্থ এই ঝুঁকিটি যে সমস্যা হতে পারে যখন এই ওএসের মাধ্যমে ডেটা সহ বিশাল ফোল্ডারটি স্থানান্তরিত করতে পারে মাঝখানে চলতে বাধা দিতে পারে উদাহরণস্বরূপ বা আলগা তথ্য
yael

উত্তর:


71

কোনও ফোল্ডারে নাম পরিবর্তন করা নিরাপদ, যদি এটি একই ফাইল সিস্টেমের মধ্যে থাকে।


যদি এটি মাউন্ট পয়েন্ট হয় ( /dataকিন্ডা দেখে মনে হচ্ছে এটি আমার কাছে মাউন্ট পয়েন্ট হতে পারে তবে এটি পরীক্ষা করে দেখুন mount), তবে আপনাকে কেবল একটি সরল ব্যতীত অন্য কিছু করতে হবে mvযেহেতু mv /data /BD_FILESতথ্যটি মূল বিভাজনে স্থানান্তরিত করবে (যা নাও হতে পারে আপনি ঘটতে চান)।

আপনার ফাইল সিস্টেমটি আনমাউন্ট করা উচিত, এখন খালি ডিরেক্টরিটির নতুন নামকরণ, আপডেট করা উচিত /etc/fstab নতুন এই ফাইল সিস্টেমের জন্য নতুন অবস্থানের সাথে এবং তারপরে পুনরায় নামকরণ করা স্থানে ফাইল সিস্টেমটি পুনরায় গণনা করুন।

অন্য কথায়,

  1. umount /data
  2. mv /data /BD_FILES (অভিমানী /BD_FILES ইতিমধ্যে বিদ্যমান নেই, সেক্ষেত্রে এটিকে প্রথমে সরিয়ে দিন)
  3. আপডেটের /etc/fstab, পরিবর্তন করা থেকে বিন্দু মাউন্ট /dataকরার/BD_FILES
  4. mount /BD_FILES

এর চারপাশে কোনও ফাইল অনুলিপি করা জড়িত না, এটি কেবলমাত্র ডিরেক্টরি সিস্টেমের নাম পরিবর্তন করে যা ফাইল সিস্টেমের মাউন্ট পয়েন্ট হিসাবে কাজ করে।


ডিরেক্টরিটির নতুন নামকরণের ক্ষেত্রে যদি এটি কোনও নতুন ফাইল সিস্টেমে স্থানান্তরিত হয় (যা অন্য ডিস্কে থাকা /dataঅবস্থায় একটি ডিস্কে থাকা অবস্থায় /BD_FILESঘটে থাকে তবে আপনি যদি জিনিসগুলিকে আরও বড় পার্টিশনে নিয়ে যান তবে করণীয় সাধারণ জিনিস) , আপনি অনুলিপিটি ঠিক আছে কিনা তা পরীক্ষা না করা পর্যন্ত মূল অক্ষত রেখে যাওয়ার সময় আমি ডেটা অনুলিপি করার পরামর্শ দিই। আপনি এটি দিয়ে করতে পারেন

rsync -a /data/ /BD_FILES/

উদাহরণস্বরূপ, তবে এটি rsyncকী করে এবং কী করে না তার জন্য ম্যানুয়ালটি দেখুন (এটি হার্ড লিঙ্কগুলি সংরক্ষণ করে না, উদাহরণস্বরূপ)।


একবার ফোল্ডারটির নাম পরিবর্তন হয়ে গেলে, আপনাকে অবশ্যই নিশ্চিত করতে হবে যে বিদ্যমান প্রক্রিয়াগুলি (প্রোগ্রাম এবং ফোল্ডার ব্যবহারকারীরা, ব্যাকআপগুলি ইত্যাদি) নাম পরিবর্তন সম্পর্কে সচেতন aware


9
ঝুঁকি রয়েছে যে কেউ mvকেবলমাত্র একটি renameসিস্টেম কল করার প্রত্যাশা করে , কিন্তু পরিস্থিতির কারণে কেউ বুঝতে পারে না যে এটি ফাইলগুলি অনুলিপি করে আসলটি মুছে ফেলবে। যদি আমার একেবারে নির্দিষ্ট হওয়া দরকার তবে কেবল একটি renameসিস্টেম কল করা হয়েছে এবং mvআমার পিঠের পিছনে কিছু "চালাক" করতে যাচ্ছি না আমি একটি পাইথন শেলটি খুলি এবং ব্যবহার করি os.rename
ক্যাস্পার্ড

3
অপেক্ষাকৃত সাম্প্রতিক লিনাক্স কার্নেলের সাহায্যে আপনি এর পরিবর্তে মাউন্ট পয়েন্টটি সরাতে পারেন:mkdir /BD_FILES && mount -M /data /BD_FILES && rmdir /data
ডেভিড ফোস্টারস্টার

2
@ মিশেল জনসন এটি সম্ভবত একটি লিনাক্স সিস্টেমে কাজ করবে, হ্যাঁ। সঙ্গে ঝরঝরে জিনিস rsyncএটি restartable হয়।
কুসালানন্দ

3
@ মিচিয়াল জনসন ওয়ান যে সরঞ্জামগুলি ব্যবহার করে সবচেয়ে স্বাচ্ছন্দ্য বোধ করেন স্পষ্টতই তা ব্যবহার করেন। হ্যাঁ, rsync -aপ্রায় সমস্ত মেটাডেটা সংরক্ষণ করে তবে হার্ড লিঙ্ক, এসিএল বা বর্ধিত বৈশিষ্ট্য নয় (এর -HAXজন্য যোগ করুন )।
কুসালানন্দ

3
@ ম্যাক্স বিভিন্ন বিতরণের renameবিভিন্ন আচরণের সাথে বিভিন্ন কমান্ড রয়েছে। আমি মনে করি এটি renameকমান্ডটি ব্যবহার না করার পক্ষে যথেষ্ট কারণ যখন আপনি নিশ্চিত হতে চান যে এটি কী করছে।
ক্যাস্পার্ড

16

আপনি ডিরেক্টরিটিতে প্রতিটি ফাইলের নাম পরিবর্তন করছেন না, আপনি একটি ফাইলের / / নাম পরিবর্তন করছেন । যে কারণ:

  1. ডিরেক্টরি ফাইল, এবং
  2. ফাইল সিস্টেমটি সত্যই ইনোডের বিষয়ে চিন্তা করে, আসল পাঠ্যটি নয়।

সুতরাং, ডিরেক্টরিটির নামকরণ, এটি যত ফাইল বা কতটা ডেটা আছে তা বিবেচনা করা তুচ্ছ।


14

যদি আপনি কেবল নাম পরিবর্তন করেন ( একই ফাইল সিস্টেমে উত্স এবং লক্ষ্য ), এটি কেবল ডিরেক্টরি এন্ট্রিটির একটি নতুন নাম। এটি হয় সফল হয় এবং ডিরেক্টরিতে নতুন নাম থাকে, বা ব্যর্থ হয় যার ক্ষেত্রে কোনও পরিবর্তন হয় না *

যদি উত্স এবং লক্ষ্যগুলি বিভিন্ন ফাইল সিস্টেমে থাকে তবে ডেটা দ্বারা অনুলিপি করা দরকার mv। ফাইল সিস্টেমের বৈশিষ্ট্যগুলির মধ্যে পার্থক্য যেমন সর্বোচ্চ ফাইলের আকার, ফাইলের নাম সীমাবদ্ধতা ইত্যাদি সমস্যার কারণ হতে পারে। সমস্যাগুলি এড়াতে প্রথমে ফাইলগুলি অনুলিপি করুন (cp ,, rsync…) এবং অনুলিপি সফলভাবে শেষ হওয়ার পরে, ফাইলগুলি মূল অবস্থানে সরিয়ে ফেলুন।

* তবে কিছু কোণার মামলা রয়েছে, উদাহরণস্বরূপ ম্যান 2 নাম পরিবর্তনের ক্ষেত্রে বুগস বিভাগে উল্লেখ করা হয়েছে


> "এটি হয় সফল হয় এবং ডিরেক্টরিটির নতুন নাম থাকে, বা ব্যর্থ হয় যার ক্ষেত্রে কিছুই পরিবর্তন হয় না"। এটি কীভাবে নিশ্চিত? এটা কি সব ফাইল সিস্টেমের জন্য সত্য? এটি সম্পর্কে কোন দলিল আছে?
turbanoff

পুনঃনামকরণ একটি একক সিস্টাল, তবে ম্যান রিমনামের BUGS বিভাগে এনএফএস সম্পর্কে একটি নোট রয়েছে: এনএফএস ব্যবহার করার সময় ত্রুটি ফিরে আসার পরেও পুনরায় নামটি সফল হতে পারে (ম্যান পৃষ্ঠায় বিশদটি দেখুন)। উত্তরে আমি একটি নোটও যুক্ত করেছি। কার্নেলের কোনও ফাইল সিস্টেমের নাম পরিবর্তন ব্যর্থ হলে ডিরেক্টরি এন্ট্রি নিখোঁজ হওয়ার জন্য এটি গ্রহণযোগ্য বলে বিবেচনা করবে বলে আমি আশা করি না।
সেবাসথ

8

অন্যরা যেমন বলেছে, কোনও ফোল্ডারটির নামকরণের বিষয়বস্তুগুলির মধ্যে অন্তর্নিহিত ঝুঁকি নেই। তবে আপনি বিবেচনা করতে চাইতে পারেন এমন এক অন্য ধরণের ঝুঁকি রয়েছে।

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

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

এরকম একটি আদেশের এটি করা উচিত: ln -s /data /BD_FILES


4
আরও একটি হালকা ঝুঁকি যা এখনও কেউ উল্লেখ করেনি, তা হ'ল সেই ফোল্ডারের জন্য আপনার ব্যাকআপ কৌশলের উপর নির্ভর করে হঠাৎ 180 গিগাবাইট "নতুন" ডেটা উপস্থিত হওয়ার কারণে ব্যাকআপ ড্রাইভে ডিস্ক স্পেস এবং বিলম্বিত সমস্যা দেখা দিতে পারে এবং এটির প্রয়োজন ব্যাক আপ করা।
কেন্ট

আমি ভালো কিছু পছন্দ mv thing1 thing2 ; ln --symbolic ./thing2 thing1। এইভাবে আমি নতুন নাম পেয়েছি এবং সহজেই সিমলিংক মোছার মাধ্যমে পুরানো অনুপস্থিতি পরীক্ষা করতে পারি।
can-ned_food

3

নতুন নামটি পারমাণবিক। একমাত্র যুক্তিসঙ্গত ঝুঁকি হ'ল mvকোনও কারণে সমস্ত কিছু অনুলিপি করার সিদ্ধান্ত নেয় এবং এটি অর্ধেকটি ক্র্যাশ হয়ে যায়। আপনি গনুহ থাকে mv, mv -Tএই ঝুঁকি মুছে ফেলা হবে।

mv -Tবলে mvযে এটি একটি নন-ফোল্ডারে চলেছে; যার ফলে এটি এমনটি করতে অস্বীকার mkdir()করবে যা কোনও ফোল্ডার সরিয়ে নেওয়া হলে এটি ব্যর্থ হয়ে যাবে এবং কোনও কারণে এটি অনুলিপি করার সিদ্ধান্ত নিয়েছে।

mv -Tকয়েক বছর আগে আমার মাস্টারের থিসিসে কাজ করার সময় আমি বাগ ঝাঁকানোতে জড়িত ছিলাম । এটি অনেকগুলি প্রান্তের ক্ষেত্রে ভুল কাজ করত।

অন্যদিকে, আপনার কাছে রুট পার্টিশনে 180GB ব্যবহারকারীর ডেটা রয়েছে। আপনি সম্ভবত এটি মূল বিভাজন থেকে সরিয়ে নিতে চান।


"রুট পার্টিশন" -তে কিছু রয়েছে কিনা তা আপনি নাম থেকে একাই সম্ভবত বলতে পারবেন না।
পিটার

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