ডিডি 1 গিগাবাইটের পরিবর্তে 32 এমবি র‌্যান্ডম ফাইল তৈরি করছে

Question

আমি একটি 1 জিবি র‌্যান্ডম ফাইল তৈরি করতে চেয়েছিলাম, তাই আমি নিম্নলিখিত কমান্ডটি ব্যবহার করেছি।

dd if=/dev/urandom of=output bs=1G count=1

তবে পরিবর্তে যতবার আমি এই কমান্ডটি চালু করি ততবারে আমি একটি 32 এমবি ফাইল পাই:

<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s

কি সমস্যা?

সম্পাদনা করুন:

এই বিষয়ে দুর্দান্ত উত্তরের জন্য ধন্যবাদ আমি এমন একটি সমাধান নিয়ে এসেছি যা 32 টি খণ্ড 32 এমবি বড় পড়ায় যা 1 জিবি করে:

dd if=/dev/urandom of=output bs=32M count=32

অন্যান্য সমাধান দেওয়া হয়েছিল যা 1 গিগাবাইট সরাসরি স্মৃতিতে পড়ে এবং তারপরে ডিস্কে লিখে দেয়। এই সমাধানটি প্রচুর স্মৃতি নেয় তাই এটি প্রিফারড না হয়:

dd if=/dev/urandom of=output bs=1G count=1 iflag=fullblock

Comments

আইএমএইচওও আমি মনে করি না যে এর জন্য অনেকগুলি বৈধ ব্যবহারের মামলা রয়েছে dd। আমি ব্যবহার করতাম head, catবা rsyncতার জায়গায় প্রায় সবসময়। বিকল্পগুলি সাধারণত নিরাপদ হওয়ার কারণগুলির একটি কারণ যদি আপনার প্রশ্ন।

— বাকুরিউ

@ বাকুরিউ - এছাড়াও, আপনি যদি কেবল জিরোতে পূর্ণ একটি ফাইল তৈরি করতে চান তবে (বা এর অভ্যন্তরে কী রয়েছে তা আপনি যত্নশীল নন) ট্র্যাঙ্কেট ব্যবহার করুন। এটা অনেক দ্রুত।

— কনরাড গাজিউস্কি

@ কনরাডগাজেউস্কি এফওয়াইআই ট্রুঙ্কেট একটি স্পার ফাইল তৈরি করার চেষ্টা করছে (যদি তা গুরুত্বপূর্ণ)

— Xen2050

@Bakuriu headছাড়া এই কাজের ব্যবহার করতে পারবেন না -cবিকল্পটি POSIX নেই । আমি কোন সংস্করণ জানি না catযার এর সমাধান করতে পারে। rsyncসম্পূর্ণরূপে মানহীন ইউটিলিটি। এটি এখানে নেই NR; এটির ম্যান পেজে স্কিমিং করে, আমি দেখতে পাচ্ছি না কীভাবে এটি এই সমস্যার সমাধান করতে পারে।

— কাজ

প্রযুক্তিগতভাবে, /dev/urandom

— পসিক্সেও নেই

Answer 1

bs, বাফার আকার, মানে ডিডিতে করা একক পঠন () কলের আকার ।

(উদাহরণস্বরূপ, উভয় bs=1M count=1এবং bs=1k count=1k1 মিবি ফাইলের ফলস্বরূপ, তবে প্রথম সংস্করণ এটি একক পদক্ষেপে করবে, দ্বিতীয়টি এটি 1024 ছোট অংশে করবে ch)

নিয়মিত ফাইলগুলি প্রায় কোনও বাফার আকারে পড়া যায় (যতক্ষণ না সেই বাফারটি র‌্যামের সাথে ফিট করে) তবে ডিভাইস এবং "ভার্চুয়াল" ফাইলগুলি প্রায়শই পৃথক কলগুলির খুব কাছাকাছি কাজ করে এবং তারা প্রতি ডেটা যে পরিমাণ ডেটা উত্পাদন করবে তার কিছু নির্বিচারে বিধিনিষেধ রয়েছে have পড়ুন () কল।

জন্য /dev/urandom, এই সীমা সংজ্ঞায়িত করা হয় urandom_read () মধ্যে ড্রাইভার / গৃহস্থালির কাজ / random.c :

#define ENTROPY_SHIFT 3

static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
    nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
    ...
}

এর অর্থ হ'ল প্রতিবার ফাংশনটি ডাকা হলে এটি অনুরোধ করা আকারটি 33554431 বাইটে চাপড়ায়।

ডিফল্টরূপে, অন্যান্য সরঞ্জামগুলির মতো নয়, dd অনুরোধের চেয়ে কম ডেটা পাওয়ার পরে পুনরায় চেষ্টা করবে না - আপনি 32 এমআইবি পাবেন এবং এটিই। (এটিকে স্বয়ংক্রিয়ভাবে পুনরায় চেষ্টা করার জন্য, কামিলের উত্তরে যেমন আপনাকে উল্লেখ করতে হবে iflag=fullblock।)

---

এটিও নোট করুন যে "একক পঠন () এর আকার" এর অর্থ হ'ল পুরো বাফারটি একবারে মেমরির সাথে ফিট করে যেতে পারে, তাই বিশাল ব্লকের আকারগুলিও ডিডির মাধ্যমে মেমরির বিশাল আকারের সাথে সঙ্গতিপূর্ণ ।

এবং এটি সমস্ত অর্থহীন কারণ usually 16–32 এমআইবি ব্লকের উপরে যাওয়ার সময় আপনি সাধারণত কোনও কার্য সম্পাদন করতে পারবেন না - সিস্কলগুলি এখানে ধীর অংশ নয়, এলোমেলো সংখ্যা জেনারেটর।

সরলতার জন্য, কেবল ব্যবহার করুন head -c 1G /dev/urandom > output।

Comments

"... – 16–32 এমআইবি ব্লকের উপরে যাওয়ার সময় আপনি সাধারণত কোনও পারফরম্যান্স অর্জন করতে পারবেন না" - আমার অভিজ্ঞতা অনুসারে, আপনি খুব বেশি লাভ করতে চান না, এমনকি 64৪-১৮২ কিলো বাইটেরও বেশি পারফরম্যান্স হারাবেন না । এই মুহুর্তে, আপনি হ্রাসকারী রিটার্ন রিস্ক সিস্টেল ব্যয়টি ভাল আছেন এবং ক্যাশে বিতর্ক ভূমিকা নিতে শুরু করে।

— মার্শেল

@ মার্কসেলাম আমি আর্কিটেক্ট উচ্চ পারফরম্যান্স সিস্টেমগুলিতে সহায়তা করেছি যেখানে ব্লকের আকার 1-2 মিমি ব্লক হয়ে যাওয়ার সাথে সাথে কিছু ক্ষেত্রে 8 এমবি বা তার বেশি হয়ে যাবে IO এর কার্যকারিতা উন্নত হবে। প্রতি LUN। আইও-র জন্য একাধিক থ্রেড ব্যবহার করে সেরা পারফরম্যান্স পেতে, একাধিক সমান্তরাল LUNs ব্যবহার করে ফাইল সিস্টেমগুলি যেমন নির্মিত হয়েছিল, প্রতিটি 1 এমবি + ব্লক করে। স্থিত আইও হারগুলি 1 জিবি / সেকেন্ডের বেশি ছিল। এবং এগুলি সমস্ত স্পিনিং ডিস্ক ছিল, তাই ব্লকটির আকার 16 বা এমনকি 32 এমবি ব্লকের আকারে বাড়ার সাথে সাথে এসএসডিগুলির উচ্চ-পারফরম্যান্স অ্যারেগুলি দ্রুত এবং দ্রুত গিলতে বা ডেটা উত্পন্ন করতে দেখতে পাচ্ছি। সহজে। আরও বড় হতে পারে।

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

আমি স্পষ্টভাবে নোট করব যে এটি পসিক্স ইউটিলিটিরiflag=fullblock একটি জিএনইউ এক্সটেনশন । যেহেতু প্রশ্নটি লিনাক্সকে নির্দিষ্ট করে না, আমি মনে করি লিনাক্স-নির্দিষ্ট এক্সটেনশনের ব্যবহার সম্ভবত স্পষ্টভাবে উল্লেখ করা উচিত যাতে কিছু ভবিষ্যত পাঠক নন-লিনাক্স সিস্টেমে অনুরূপ সমস্যা সমাধানের চেষ্টা করছেন তবে বিভ্রান্ত হবেন না। dd

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

@ অ্যান্ড্রুহেনেল আহ, আকর্ষণীয়! আমি ddআমার মেশিনে 1k থেকে 512M অবধি ব্লক আকার সহ একটি দ্রুত পরীক্ষা করেছি। একটি ইন্টেল 750 এসএসডি থেকে পড়া, 2MiB ব্লকে অনুকূল পারফরম্যান্স (প্রায় 1300MiB / গুলি) অর্জন করা হয়েছিল, আপনার ফলাফলগুলির সাথে মোটামুটি মিলছে। বৃহত্তর ব্লক আকারগুলি কোনওরূপে সহায়তা করে বা বাধা দেয় না। থেকে পড়া /dev/zero, সর্বোত্তম কর্মক্ষমতা (প্রায় 20GiB / গুলি) ছিল 64KiB এবং 128KiB ব্লকে; ছোট এবং বৃহত উভয় ব্লকই আমার পূর্ববর্তী মন্তব্যের সাথে মোটামুটি মিলছে performance নীচের লাইন: আপনার আসল পরিস্থিতির জন্য মানদণ্ড। এবং অবশ্যই, আমরা /dev/random

— উভয়ই

@ Xen2050 আমি আরও কিছু দ্রুত পরীক্ষা করেছি এবং এটি ddদ্রুত গতিতে দেখা যাচ্ছে। একটি দ্রুত headস্ট্রেসে দেখানো হয়েছে যে 8KiB রিড ব্যবহার করেছে এবং দুটি 4KiB লিখেছেন, যা আকর্ষণীয় (জিবিইউ কোর্টিলস 8.26 ডেবিয়ান 9.6 / লিনাক্স 4.8)। headগতি প্রকৃতপক্ষে কোথাও dd bs=4kএবং এর মধ্যে dd bs=8k। headতুলনায় গতি নীচে ~ 40% dd if=/dev/zero bs=64kএবং তুলনায় 25% কম dd if=/dev/nvme0n1 bs=2M। পাঠ্যগুলি /dev/zeroঅবশ্যই আরও সিপিইউ-সীমিত, তবে এসএসডি-র জন্য I / O কুইংয়ের ভূমিকাও রয়েছে। এটি আমার প্রত্যাশার চেয়ে বড় পার্থক্য।

— মার্সেলেম

Answer 2

ddনির্দিষ্ট না করা থাকলে ibs(দ্রষ্টব্য: bsউভয় ibsএবং সুনির্দিষ্ট obs) এর চেয়ে কম পড়তে পারে iflag=fullblock। 0+1 records inইঙ্গিত দেয় যে 0পুরো ব্লক এবং 1আংশিক ব্লকটি পড়া হয়েছিল। তবে কোনও পূর্ণ বা আংশিক ব্লক কাউন্টারকে বাড়িয়ে তোলে।

এই নির্দিষ্ট ক্ষেত্রে ddতুলনামূলক কম ব্লকটি পড়ার সঠিক ব্যবস্থাটি আমি জানি না 1G। আমি অনুমান করি যে কোনও ব্লক লেখার আগে মেমরিটিতে পড়েছে, যাতে মেমরি পরিচালনাটি হস্তক্ষেপ করতে পারে (তবে এটি কেবল অনুমান)। সম্পাদনা করুন: এই সমবর্তী উত্তরটি এমন ব্যবস্থাকে ব্যাখ্যা করে যা এই নির্দিষ্ট ক্ষেত্রে ddতুলনামূলক কম ব্লকটি পড়তে সক্ষম 1Gকরে।

যাইহোক, আমি এত বড় প্রস্তাব দিই না bs। আমি ব্যবহার করব bs=1M count=1024। সর্বাধিক গুরুত্বপূর্ণ বিষয়টি: iflag=fullblock কোনও পাঠ্য প্রচেষ্টা ব্যতীত কম পড়তে পারে ibs(যতক্ষণ না ibs=1, আমি মনে করি, এটি যদিও যথেষ্ট অক্ষম)।

সুতরাং আপনার যদি কিছু সঠিক পরিমাণের ডেটা পড়তে হয় তবে ব্যবহার করুন iflag=fullblock। নোট iflagPOSIX দ্বারা প্রয়োজন হয় না, আপনি ddএটি সমর্থন নাও করতে পারেন। এই উত্তর অনুসারে ibs=1সম্ভবত সঠিক সংখ্যা বাইট পড়ার একমাত্র পসিক্স উপায়। অবশ্যই যদি আপনি পরিবর্তন করেন ibsতবে আপনার অবশ্যই পুনরায় গণনা করতে হবে count। আপনার যদি কমিয়ে ibsকরার 32Mবা তার কম সম্ভবত ছাড়া, সমস্যা ঠিক করবে iflag=fullblock।

আমার কুবুন্টুতে আমি আপনার আদেশটি এইভাবে ঠিক করব:

dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock