অবাস্তব সাধারণ ডিএম-ক্রিপ্ট (LUKS) লেখার কর্মক্ষমতা


21

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

সংক্ষেপে প্রশ্ন: ব্লক ডিভাইসে (~ 170MB / s) বিআরটিএফ লাগানোর সময় আমি কেন পুরোপুরি দ্রুত লেখার গতি পাই, যখন লেখার গতিটি ডিএম-ক্রিপট / এলইউকেএসের মধ্যে রাখার সময় (M 20MB / s) ডুবে যায়? ফাইল সিস্টেম এবং ব্লক ডিভাইস, যদিও সিস্টেমটি যথেষ্ট উচ্চ এনক্রিপশন মাধ্যমে আউটপুট বজায় রাখতে সক্ষম?

দৃশ্যপট

/home/schlimmchen/random/dev/urandomপূর্ববর্তী থেকে ডেটা ভরা একটি 4.0 জিবি ফাইল ।

dd if=/dev/urandom of=/home/schlimmchen/Documents/random bs=1M count=4096

এটি পড়া অত্যন্ত দ্রুত:

$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 6.58036 s, 648 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 0.786102 s, 5.4 GB/s

(দ্বিতীয়বার, ফাইলটি অবশ্যই ক্যাশে থেকে পড়েছিল)।

এনক্রিপ্ট করা বিটিআরএফএস

ডিভাইসটি সরাসরি বিটিআরএফএস (ব্লক ডিভাইসে কোনও বিভাজন সারণী) দিয়ে ফর্ম্যাট করা হয়।

$ sudo mkfs.btrfs /dev/sdf
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt

লেখার গতি ~ 170MB / s এর চেয়ে বেশি হয়ে যায়:

$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.1564 s, 157 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 25.1882 s, 169 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test3 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 29.8419 s, 143 MB/s

পড়ার গতি 200MB / s এর চেয়েও ভাল।

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8265 s, 215 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.9821 s, 213 MB/s
$ dd if=/mnt/dd-test3 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8561 s, 215 MB/s

ব্লক ডিভাইসে এনক্রিপ্ট করা বিটিআরএফস

ডিভাইসটি LUKS দিয়ে ফর্ম্যাট করা হয়েছে এবং ফলস্বরূপ ডিভাইসটি বিটিআরএফএস দিয়ে ফর্ম্যাট করা হয়েছে:

$ sudo cryptsetup luksFormat /dev/sdf
$ sudo cryptsetup luksOpen /dev/sdf crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /mnt
$ sudo chmod 777 /mnt
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 210.42 s, 20.3 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M 
4265841146 bytes (4.3 GB) copied, 207.402 s, 20.6 MB/s

পড়ার গতি কেবলমাত্র প্রান্তিকভাবে ভোগে (কেন এটি সর্বদা হয়?):

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.2002 s, 192 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.0794 s, 193 MB/s

লুক্সডাম্প: http://pastebin.com/i9VYRR0p

ব্লক ডিভাইসে বিটিআরএফএসে ফাইলটিতে এনক্রিপ্ট করা বিটিআরএফএস

এনক্রিপ্ট করা ফাইলটিতে লেখার সময় 150 এমবি / সেকেন্ডে লেখার গতি "স্কাইরোকেটস"। আমি ব্লক ডিভাইসে একটি বিটিআরএফস রেখেছি, একটি 16 জিবি ফাইল বরাদ্দ করেছি, যা আমি lukfsFormatসম্পাদনা করেছি এবং মাউন্ট করেছি।

$ sudo mkfs.btrfs /dev/sdf -f
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt
$ dd if=/dev/zero of=/mnt/crypted-file bs=1M count=16384 conv=fsync
17179869184 bytes (17 GB) copied, 100.534 s, 171 MB/s
$ sudo cryptsetup luksFormat /mnt/crypted-file
$ sudo cryptsetup luksOpen /mnt/crypted-file crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /tmp/nested/
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 26.4524 s, 161 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.5601 s, 155 MB/s

লেখার পারফরম্যান্স কেন এভাবে বাড়ছে? উচ্চতর লেখার গতিতে সহায়তা করতে ফাইল সিস্টেম এবং ব্লক ডিভাইসের এই বিশেষ বাসা কী অর্জন করে?

সেটআপ

একই ডিস্ট্রো এবং কার্নেল চালিত দুটি সিস্টেমে সমস্যা পুনরুত্পাদনযোগ্য। তবে, আমি সিস্টেম 2-তে কার্নেল 3.19.0 এর সাথে কম লেখার গতিও পর্যবেক্ষণ করেছি।

  • ডিভাইস: সানডিস্ক এক্সট্রিম 64 জিবি ইউএসবি 3.0 ইউএসবি স্টিক
  • সিস্টেম 1: ইন্টেল এনইউসি 5i5RYH, i5-5250U (ব্রডওয়েল), 8 জিবি র‌্যাম, স্যামসং 840 ইভিও 250 জিবি এসএসডি
  • সিস্টেম 2: লেনোভো টি 440 পি, আই 5-4300 এম (হাসওয়েল), 16 জিবি র‌্যাম, স্যামসং 850 প্রো 256 জিবি এসএসডি
  • ডিস্ট্রো / কার্নেল: দেবিয়ান জেসি, 3.16.7
  • cryptsetup: 1.6.6
  • /proc/cryptoসিস্টেম 1 এর জন্য: http://pastebin.com/QUSGMfiS
  • cryptsetup benchmarkসিস্টেম 1 এর জন্য: http://pastebin.com/4RxzPFeT
  • বিটিআরএফএস (-টুলস) সংস্করণ 3.17
  • lsblk -t /dev/sdf: http://pastebin.com/nv49tYWc

থটস

  • প্রান্তিককরণ যতদূর আমি দেখতে পাচ্ছি কারণ নয় । এমনকি কাঠির পৃষ্ঠার আকার 16KiB হলেও, ক্রিপসেটআপ পেলোড শুরুটি যাইহোক 2MiB তে প্রান্তিক করা আছে।
  • --allow-discards (ক্রিপ্টসেটআপের লুকস ওপেনের জন্য) সাহায্য করেনি, যেমনটি আমি প্রত্যাশা করছিলাম।
  • এটির সাথে অনেক কম পরীক্ষা-নিরীক্ষা করার সময়, আমি একটি ইউএসবি 3.0 অ্যাডাপ্টারের মাধ্যমে সংযুক্ত একটি বাহ্যিক হার্ড ড্রাইভের সাথে খুব অনুরূপ আচরণ লক্ষ্য করেছি।
  • আমার কাছে মনে হচ্ছে সিস্টেমটি 64KiB ব্লক লিখছে। একটি সিস্টেমট্র্যাপ স্ক্রিপ্ট আমি চেষ্টা করেছি যা কমপক্ষে নির্দেশ করে। /sys/block/sdf/statপ্রচুর লেখাগুলি একত্রিত হওয়ার পরে এই অনুমানকে সমর্থন করে। সুতরাং আমার অনুমান যে খুব ছোট ব্লকে লেখার কারণ নয়।
  • ব্লক ডিভাইস কিউ শিডিয়ুলারটি NOOP এ পরিবর্তন করার জন্য ভাগ্য নেই।
  • ক্রিপ্টটিকে একটি এলভিএম ভলিউমের মধ্যে রাখলে কোনও লাভ হয়নি।

প্রতিটি পরীক্ষার আগে ডিস্ক ক্যাশে সাফ করার ফলে এটি গতির সম্ভাব্য কারণ হিসাবে মুছে ফেলা হবে (বর্তমানে ra৪৮ এমবি / গুলি অযৌক্তিকভাবে ম্যামের বাইরে)
Xen2050

উত্তর:


18

উত্তর (যেমন আমি এখন জানি): সম্পাতবিন্দু

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

প্রশমন ("পুরানো" কার্নেলের জন্য)

নেতিবাচক প্রভাবটি এই জাতীয় আইও শিডিউলারের কাতারে সারিযুক্ত অনুরোধের পরিমাণ বাড়িয়ে হ্রাস করা যেতে পারে:

echo 4096 | sudo tee /sys/block/sdc/queue/nr_requests

আমার ক্ষেত্রে এটি প্রায় ত্রিগুণ (~ 56MB / s) 4 জিবি র্যান্ডম ডেটা পরীক্ষার জন্য আমার প্রশ্নের উত্তর ব্যাখ্যা করেছে question অবশ্যই, এনক্রিপ্ট করা আইওয়ের তুলনায় পারফরম্যান্সটি 100MB / s এর চেয়ে কম falls

তদন্ত

মাল্টিকোর blktrace

আমি আরও সমস্যাযুক্ত পরিস্থিতিটি তদন্ত করেছি যেখানে একটি বিটিআরএফস একটি এলইউকেএস এনক্রিপ্টড ব্লক ডিভাইসের শীর্ষে রাখা হয়েছে। প্রকৃত ব্লক ডিভাইসে কী লেখার নির্দেশাবলী জারি করা হয়েছে তা দেখানোর জন্য, আমি এটি ব্যবহার করেছি blktrace:

sudo blktrace -a write -d /dev/sdc -o - | blkparse -b 1 -i - | grep -w D

এটি যা করে (যতদূর আমি বুঝতে পেরেছি) হ'ল আইও অনুরোধটি /dev/sdcযা " লিখুন " টাইপের টাইপ করা হয়েছে , তারপরে এটি মানব পাঠযোগ্য আউটপুটকে বিশ্লেষণ করুন তবে আউটপুটটিকে " ডি " কে সীমাবদ্ধ করুন , যা (অনুযায়ী man blkparse) " ড্রাইভারকে আইও জারি করা হয়েছে "।

ফলাফলটি এরকম কিছু ছিল ( মাল্টিকোর লগের প্রায় 5000 লাইনের আউটপুট দেখুন ):

8,32   0    32732   127.148240056     3  D   W 38036976 + 240 [ksoftirqd/0]
8,32   0    32734   127.149958221     3  D   W 38038176 + 240 [ksoftirqd/0]
8,32   0    32736   127.160257521     3  D   W 38038416 + 240 [ksoftirqd/0]
8,32   1    30264   127.186905632    13  D   W 35712032 + 240 [ksoftirqd/1]
8,32   1    30266   127.196561599    13  D   W 35712272 + 240 [ksoftirqd/1]
8,32   1    30268   127.209431760    13  D   W 35713872 + 240 [ksoftirqd/1]
  • কলাম 1: প্রধান, ব্লক ডিভাইসের গৌণ
  • কলাম 2: সিপিইউ আইডি
  • কলাম 3: ক্রম সংখ্যা
  • কলাম 4: সময় স্ট্যাম্প
  • কলাম 5: প্রক্রিয়া আইডি
  • কলাম 6: ক্রিয়া
  • কলাম 7: আরডাব্লুবিএস ডেটা (প্রকার, ক্ষেত্র, দৈর্ঘ্য)

এটি ddমাউন্ট করা ফাইল সিস্টেমে 4 জিবি র্যান্ডম ডেটা যুক্ত করার সময় উত্পাদিত আউটপুটটির স্নিপড । এটি পরিষ্কার যে কমপক্ষে দুটি প্রক্রিয়া জড়িত। বাকী লগটি দেখায় যে চারটি প্রসেসর আসলে এতে কাজ করছে। দুঃখের বিষয়, লেখার অনুরোধগুলি আর অর্ডার করা হয় না। সিপিইউ 0 38038416 তম সেক্টরের আশেপাশে কোথাও লিখছে, সিপিইউ 1 যা পরে নির্ধারিত হয়েছে, 35713872 তম সেক্টরের আশেপাশে লিখছে। এটা খারাপ.

একটি কোর blktrace

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

কটাক্ষপাত আছে singlecore লগ আউটপুট 5000 সম্পর্কে লাইন

আলোচনা

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

বর্তমান কার্নেলগুলিতে স্থির (> = 4.0.2)

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

রেকর্ড এর জন্য:

$ uname -a
Linux t440p 4.0.0-1-amd64 #1 SMP Debian 4.0.2-1 (2015-05-11) x86_64 GNU/Linux
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test bs=1M conv=fsync
4294967296 bytes (4.3 GB) copied, 29.7559 s, 144 MB/s

মিকুলাস পাতোকাকে একটি টুপি, যিনি এই প্রতিশ্রুতি রচনা করেছিলেন।


1
আমি কার্নেল 4.12.12 এর সাহায্যে লুকিয়ে বিটিআরএফ ব্যবহার করছি এবং মন্দা এখনও আছে!
ব্রেলিওলো

কেন আপনি বলছেন যে মন্দা এখনও আছে? আপনি কোন রেফারেন্সটি ব্যবহার করছেন যাতে আপনি মন্দা অনুভব করেননি? আপনার সেটআপ কি? আপনি কেবল LUKS অপসারণ করার সময় ড্রাইভের কার্যকারিতা পরীক্ষা করে দেখেছেন?
schlimmchen

খুঁজে বের করার LUKS সম্পর্কিত সম্পর্কযুক্ত নিশ্চিত unix.stackexchange.com/a/393521/39985
brauliobo

1
এখন আমি বুঝতে পেরেছি কেন আপনি এখনও "ধীরগতির" অভিজ্ঞতা নিয়ে লিখবেন। তবে আপনার সমস্যা নিছক এটির সাথে সম্পর্কিত, এটি অবশ্যই একই সমস্যা নয় (পিছিয়ে থাকা বনাম কম পারফরম্যান্স)। আমি এই বিরক্তিকর হিকআপগুলিও অভিজ্ঞতা করি, তাই আপনি এখানে আপনার সমস্যাটি উল্লেখ করেছেন বলে আমি অত্যন্ত কৃতজ্ঞ! LUKS ব্যবহার না করা কোনও বিকল্প নয়, তবে এটি জেনে রাখা ভাল যে এটি কারণের সাথে সম্পর্কিত।
schlimmchen
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.