ডিস্ক পূর্ণ না হওয়া পর্যন্ত `tar`` dd` এ পাইপিং কেন থামবে না?

Question

আমার কাছে একটি একক ডিস্ক চিত্রের একটি সংরক্ষণাগার রয়েছে। এই টার ফাইলের অভ্যন্তরের চিত্রটি প্রায় 4 গিগাবাইট আকারের। আমি নল আউটপুট tar xfমধ্যে ddএকটি SD কার্ডে ডিস্ক ইমেজ লিখতে। কার্ডটি পূর্ণ না হওয়া পর্যন্ত ডিস্কডাম্প কখনও থামে না। এখানে আমার শেল সেশন:

$ ls -l disk.img.tgz
-rw-r--r-- 1 confus confus 192M Okt  5 00:53

$ tar -tvf disk.img.tgz
-rw-r--r-- root/root 4294968320 2018-10-05 00:52 disk.img

$ lsblk -lb /dev/sdc
NAME MAJ:MIN RM        SIZE RO TYPE MOUNTPOINT
sdc    8:32   1 16022241280  0 disk

$ tar zxf disk.img.tgz -O | sudo dd status=progress conv=sync bs=1M of=/dev/sdc
[sudo] password for user: 
15992881152 bytes (16 GB, 15 GiB) copied, 212 s, 75,4 MB/s 
dd: error writing '/dev/sdc': No space left on device
0+15281 records in
15280+0 records out
16022241280 bytes (16 GB, 15 GiB) copied, 217,67 s, 73,6 MB/s

কেন? হিটটি 16 গিগাবাইট কার্টে 4 গিগাবাইট চিত্রটি লেখার পরে থামাতে হবে এবং কখনই স্থানের বাইরে চলে যাবে!

Comments

এটি চালিয়ে যাওয়ার ddএবং অন্য কোনও ফাইলে লেখার চেষ্টা করার জন্য আপনার কাছে কি ডিস্কের জায়গা আছে ? tar zxf disk.img.tgz -O | dd status=progress conv=sync bs=1M of=/path/to/some/file/on/disk? যদি তা হয় তবে তা কি আপনাকে আসল ফাইলটির একটি অনুলিপি পেতে পারে?

— অ্যান্ডি ডাল্টন

তুমি কেন conv=sync? আপনি conv=fsyncসম্ভবত ব্যবহার করতে চাইছেন ?

— রাল্ফ রনকুইস্ট

আপনি কি নিশ্চিত যে ফাইলটির আসল আকার? আমি জানি gzip এর 32 টি বিট রয়েছে যার মধ্যে ফাইলের আকার সংরক্ষণ করা যায়, সুতরাং এটি 4GB এর চেয়ে বেশি ফাইলের আকার পায়। আমি নিশ্চিত নই যে টারের সীমাবদ্ধতা আছে কিনা।

— ডেভিড কনরাড

Answer 1

এটি কারণ আপনি এটি ভুল করছেন।

আপনি ব্যবহার করছেন bs=1Mতবে স্টিডিন, পাইপ থেকে পড়তে আরও ছোট পড়বে। আসলে, ডিডি অনুসারে, আপনি একটিও পুরো পঠন পাননি।

এবং তারপরে আপনার কাছে conv=syncযা শূন্যগুলি সহ অসম্পূর্ণ পড়া সম্পূর্ণ করে।

0+15281 records in
15280+0 records out

dd0 টি পূর্ণ এবং 15281 অসম্পূর্ণ পাঠ পেয়েছে এবং 15280 পূর্ণ ব্লক লিখেছিল (কনভ = সিঙ্ক শূন্য ভরা)। সুতরাং আউটপুট ইনপুটটির চেয়ে অনেক বড়, যতক্ষণ না আপনি কোনও স্থান বাকি রাখেন না।

   sync   pad  every  input  block  with  NULs to ibs-size; when used with
          block or unblock, pad with spaces rather than NULs

এটি সমাধান করার জন্য, আপনি মুছে ফেলতে conv=syncএবং যুক্ত করতে পারেন iflag=fullblock।

---

উদাহরণস্বরূপ, বিবেচনা করুন yes, যা ডিফল্টরূপে অসীম "y \ ny \ ny \ n" আউট দেয়।

$ yes
y
y
y
^C
$ yes | hexdump -C
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*

সঙ্গে dd bs=1M conv=syncএটা ভালো দেখায়:

$ yes | dd bs=1M conv=sync | hexdump -C
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
0001e000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
00112000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

সুতরাং এটি "y \ ny \ ny \ n" (0x00000 - 0x1e000, 122880 বাইট) এর একটি অসম্পূর্ণ ব্লক পেয়েছে তারপরে অবশিষ্ট 1M শূন্য হিসাবে লিখবে (0x01e000 - 0x100000, 925696 বাইট)। বেশিরভাগ ক্ষেত্রে, আপনি এটি চান না। ফলাফল যেভাবেই হোক এলোমেলোভাবে যেমন প্রতিটি পড়ার ক্ষেত্রে কতটা অসম্পূর্ণ হতে পারে তার কোনও বাস্তব নিয়ন্ত্রণ আপনার নেই। এখানে যেমন দ্বিতীয় পঠনটি আর 122880 বাইট নয় তবে 73728 বাইট।

dd conv=syncখুব কমই কার্যকর এবং এমন ক্ষেত্রেও যেখানে এটি স্বাগত হবে, যেমন জিরো লেখার সময় যখন আপনি ত্রুটিগুলি পড়েন, জিনিসগুলি এটির সাথে মারাত্মকভাবে ভুল হয়ে যায়।

Comments

এই ক্ষেত্রে, (ধরে নিলে লিনাক্স) ddঅধীনে কমান্ডটি চালানো হলে straceপাইপ থেকে প্রতিটি সংক্ষিপ্ত পঠন পুরো 1 এমবি রচনা অনুসরণ করা যায়।

— অ্যান্ড্রু হেনেল

@ অ্যান্ড্রুহেনেল এর জন্য এমনকি স্ট্রেসেরও দরকার নেই, কেবল আউটপুটটি দেখে তা করবে। একটি দৃষ্টান্ত যুক্ত করা হয়েছে

— frostschutz

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

— আর ..

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

— কন-এফ-ব্যবহার

@ আর .., ডিভাইস ড্রাইভারদের কাছে সেই বৈশিষ্ট্যটি খুব কার্যকর যেগুলি পড়া এবং লেখার ব্লক আকারের বিষয়ে যত্নশীল। আমার মনে আছে কিছু টেপ ড্রাইভ ব্যবহার করা হয়েছে যা এটি সম্পর্কে যত্নশীল ছিল। যদিও এই ক্ষেত্রে এটি স্পষ্টতই প্রয়োজনীয় নয়, কেউ সরাসরি ডিস্কে সরাসরি পুনঃনির্দেশ করতে পারে (যদিও সরাসরি প্রগতির প্রতিবেদন পাচ্ছে না)

— ইলক্কাচু