ইউএসবি মেমরি স্টিক কপি সত্যিই ধীর?


45

আমি যখন ইউএসবি ডিভাইসে ফাইলগুলি অনুলিপি করি তখন এটি উইন্ডোজ (একই ইউএসবি ডিভাইস, একই পোর্ট) এর তুলনায় অনেক বেশি সময় নেয় এটি ইউএসবি ১.০ গতি (১ এমবি / এস) এর চেয়ে দ্রুত কিন্তু ইউএসবি ২.০ গতি (12 এমবি / গুলি) এর চেয়ে অনেক ধীর হয়। 1.8 গিগাবাইট অনুলিপি করতে আমার 10 মিনিটের বেশি সময় লাগে (এটি হওয়া উচিত <3 মিনিট) আমার দুটি অভিন্ন সানডিস্ক ক্রুজার 8 জিবি লাঠি রয়েছে এবং আমার উভয়ের ক্ষেত্রে একই সমস্যা রয়েছে। আমার কাছে পার্শ্ববর্তী বন্দরটিতে একটি সুপার ট্যালেন্ট 32 জিবি ইউএসবি এসএসডি রয়েছে এবং এটি প্রত্যাশিত গতিতে কাজ করে।

জিইউআইতে আমি যে সমস্যাটি দেখতে পাচ্ছি তা হ'ল অগ্রগতি বারটি তাত্ক্ষণিকভাবে 90% এ চলে যায়, 100% থেকে একটু ধীর হয়ে যায় এবং 10 মিনিটের জন্য সেখানে স্তব্ধ হয়ে যায়। এই মুহুর্তে অনুলিপিটিতে বাধা দেওয়ার ফলে ফাইলের লেজ প্রান্তে দুর্নীতি দেখা দিয়েছে। আমি যদি অপেক্ষা করি তবে এটি অনুলিপিটি সম্পূর্ণ হবে।

কোন ধারনা? dmesg আউটপুট নীচে:

[64059.432309] usb 2-1.2: new high-speed USB device number 5 using ehci_hcd
[64059.526419] scsi8 : usb-storage 2-1.2:1.0
[64060.529071] scsi 8:0:0:0: Direct-Access     SanDisk  Cruzer           1.14 PQ: 0 ANSI: 2
[64060.530834] sd 8:0:0:0: Attached scsi generic sg4 type 0
[64060.531925] sd 8:0:0:0: [sdd] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
[64060.533419] sd 8:0:0:0: [sdd] Write Protect is off
[64060.533428] sd 8:0:0:0: [sdd] Mode Sense: 03 00 00 00
[64060.534319] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.534327] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.537988] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.537995] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.541290]  sdd: sdd1
[64060.544617] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.544619] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.544621] sd 8:0:0:0: [sdd] Attached SCSI removable disk

অন্যান্য কার্য দ্রুত সম্পাদনের বিনিময়ে লিনাক্স ডিফার ডিস্ক লেখেন। কেবল অনুমান করুন, দৌড়াতে চেষ্টা করুন syncএবং দেখুন এটি প্রক্রিয়াটিকে গতি দেয় না কিনা। <-
অরক্ষিত

এটির কোনও অর্থ নেই যে এটি এক ধরণের ইউএসবি নয় তবে অন্যটির জন্য স্থগিত করবে। এছাড়াও আমি প্রতি 30 সেকেন্ড বা তারপরে লিনাক্স কলগুলি সিঙ্ক পুনরায় মনে করব? পুরানো হতে পারে। আমি আশা করছি এটি কোনও ধরণের ড্রাইভার বা সামঞ্জস্যতার সমস্যা কারণ এটি ডিভাইসের ধরণের উপর নির্ভর করে।
এলফ

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

" প্রতিবেশী বন্দরে আমার কাছে একটি সুপার ট্যালেন্ট 32 জিবি ইউএসবি এসএসডি রয়েছে এবং এটি প্রত্যাশিত গতিতে কাজ করে।" এটি সেখানে ছিল, তবে আমি গোপনে স্বীকার করব :) তবে এই এইচডিপর্মের জিনিসটি আপনি কীসের প্রতিশ্রুতি দিয়েছিলেন?
এলফ

ঠিক আছে, এসএসডি এবং ফ্ল্যাশ মেমরি একই জিনিস নয়। তবে পাশাপাশি চলতে, এইচডিপর্মটি একটি ইউটিলিটি যা আপনাকে ম্যানুয়ালি ড্রাইভের জন্য অ্যাক্সেস / স্পিনের গতি সেট করতে দেয়
রোবটহম্যানস

উত্তর:


29

আমার ইউএসবি ড্রাইভে অনুলিপি কেন লিনাক্সের (এবং উইন্ডোতে দ্রুত) কম?

কারণ ১. ফাইল ক্যাচিং লেখাগুলিকে ধীর বা দ্রুত প্রদর্শিত করতে পারে appear

জিইউআইতে আমি যে সমস্যাটি দেখতে পাচ্ছি তা হ'ল অগ্রগতি বারটি তাত্ক্ষণিকভাবে 90% এ চলে যায়, 100% থেকে একটু ধীর হয়ে যায় এবং 10 মিনিটের জন্য সেখানে স্তব্ধ হয়ে যায়।

একটি জিনিস আপনার বোঝা দরকার ফাইল ক্যাচিং c লিনাক্স (এবং উইন্ডোজ) অন্যথায় "খালি" র‌্যাম ব্যবহার করে পাঠ / লেখার ক্রিয়াকলাপগুলিকে ক্যাশে করে এবং পরবর্তী অ্যাক্সেসগুলিতে দ্রুততর করে তুলবে। ডিভাইসে ধীরে ধীরে কপি অপারেশনগুলি ক্যাচ করা আপনার আচরণের ফলাফল হিসাবে দেখা যায় - "দ্রুত সমাপ্তি" আসলে ক্যাশে লেখা হয় এবং তারপরে এটি ধীর হয়ে যায় এবং বন্ধ হয়ে যায় কারণ ক্যাশে (সিঙ্ক) ডেটাতে স্লো ডিভাইসে ডেটাটির আসল ফ্লাশিং হ'ল খুব দীর্ঘ সময় নিচ্ছে। আপনি যদি সেই মুহূর্তে গর্ভপাত করেন তবে সিঙ্কটি কখনই শেষ না হওয়ায় ডেটাটি কলুষিত হয় (যেমন আপনি উল্লেখ করেছেন)।

উইন্ডোজে এই জাতীয় অনুলিপিটি দ্রুত বলে মনে হতে পারে (উল্লিখিত এমবি / সেকেন্ডের গতি সহ) কারণ কখনও কখনও উইন্ডোজ সিঙ্কের জন্য অপেক্ষা না করে এবং ডেটা ক্যাশে লিখিত হওয়ার সাথে সাথেই কাজটি সম্পন্ন ঘোষণা করে।

কারণ ২. প্রচুর ফাইল, বিশেষত ছোট ছোটগুলি লেখা ধীর

1.8 জিবি অনুলিপি করতে

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

কারণ ৩. একটি ইউএসবি স্টিকের গতি লিখুন এবং একটি এসএসডি তুলনা করা যায় না

আমার কাছে পার্শ্ববর্তী বন্দরটিতে একটি সুপার ট্যালেন্ট 32 জিবি ইউএসবি এসএসডি রয়েছে এবং এটি প্রত্যাশিত গতিতে কাজ করে।

  • একটি বাগানের বিভিন্ন ধরণের ইউএসবি স্টিকে সাধারণত ফ্ল্যাশ মেমরি চিপ থাকে যা সিরিয়ালি (ক্রমানুসারে) লেখা হয় এবং এর নিজস্ব কোনও ক্যাশে নেই।

  • অন্যদিকে, একটি এসএসডিতে এমন একটি নিয়ামক রয়েছে যা ফ্ল্যাশ মেমরি চিপগুলিকে সমান্তরালভাবে লিখে , ইউএসবি স্টিকের উপর 2 বা ততোধিক ফ্যাক্টরের মাধ্যমে থ্রুটপুট বৃদ্ধি করে।

    • যদি আপনার 32 জিবি এসএসডিতে 4x 8 জিবি চিপস থাকে তবে এটি কোনও লিখন ক্রিয়াকলাপে ইউএসবি স্টিকের চেয়ে 4x দ্রুততর হবে।
    • এসএসডি এছাড়াও তাই এটি দ্রুত ক্যাশের মধ্যে ইনকামিং তথ্য সংরক্ষণ এবং, অপারেটিং সিস্টেম এটি সম্পন্ন বলতে এটি এখনও আসলে ফ্ল্যাশ মেমরি যে ডেটা লিখতে হয়েছে যখন করতে পারেন র্যাম ক্যাশে (হার্ড ডিস্ক মত) রয়েছে।
  • সুতরাং, একটি বড় ফাইলের সাথে, আমরা ধরে নিয়েছি 4x কাঠামোর সাথে আপনার 32 জিবি গিগাবাইটটি দ্রুত 4x হবে; অনেকগুলি ছোট ফাইল সহ এটি 10x বা আরও দ্রুততর হবে কারণ এটি সেগুলি বুদ্ধি করে তার ক্যাশে সংরক্ষণ করতে পারে।


সংক্ষেপে , লিনাক্সে ইউএসবি স্টিকগুলিতে ফাইল অনুলিপিটি ধীরে ধীরে প্রদর্শিত হতে পারে তার কারণগুলি। এটি কোনও হার্ডওয়্যার / ড্রাইভার ইস্যু বা যা কিছু কারণে আসলে ধীর হয় ...

লিনাক্স এবং উইন্ডোজের মধ্যে লেখার গতির একটি যথাযথ তুলনা করা

  • প্রথমত, এসএসডি সম্পর্কে 3 কারণে ভুলে যান It's এটি কমলা এবং আপেলের মতো।
  • কারণ 1 (ক্যাশিং) এবং কারণ 2 (ছোট ফাইল) এর প্রভাবগুলি এড়িয়ে যাওয়ার জন্য আপনাকে পরীক্ষা সিস্টেমে র‌্যামের পরিমাণের চেয়ে বড় একটি একক বড় ফাইল দিয়ে পরীক্ষা করতে হবে।
  • লিনাক্সে আপনি এটি দিয়ে এটি তৈরি করতে পারেন dd if=/dev/urandom of=largetest bs=1M count=7500যা আপনাকে একটি 7500 এমবি পরীক্ষার ফাইল দেয়। ধরে নিই আপনার সিস্টেমে 4 গিগাবাইটের চেয়ে কম র‌্যাম রয়েছে, এটি যথেষ্ট ভাল। এটি একটি সদ্য ফর্ম্যাটেড স্যান্ডিস্ক 8 জিবি স্টিকে অনুলিপি করুন এবং এটির সময় দিন।
  • উইন্ডোতে পুনরায় বুট করুন, এবং largetestইউএসবি স্টিক থেকে আপনার হার্ড ডিস্কে অনুলিপি করুন । পুনরায় বুট করুন (এটিকে ক্যাশে থেকে সরাতে)। তারপরে ইউএসবি স্টিকটি ফর্ম্যাট করুন (একই ভিফ্যাট / এফএটি 32!) এবং largetestহার্ড ডিস্ক থেকে স্টিকে অনুলিপি করুন ।
  • কিভাবে সময় তুলনা করতে পারি?

2
সিসি: @ অলফ পুনরায় কারণ 1 : হ্যাঁ, ক্যাশে সিঙ্ক করা অবশ্যই আপাত লেখার সময়গুলিকে প্রভাবিত করতে পারে। তবে ক্যাশে একাই ব্যাখ্যা করবে কেন এটি সেখানে 10 মিনিটের জন্য স্থির থাকে ?? আমি মনে করি ওপি থেকে আমাদের আরও বিশদ প্রয়োজন। পুনরায় কারণ 2 : আপনি কেন অনুমান করি এই স্থানান্তর অনেক ছোট ফাইল গঠিত? আমি মনে করি না ওপি এই 1.8 জিবি স্থানান্তর সম্পর্কে কোনও বিবরণ সরবরাহ করে, সে কি? পুনরায় কারণ 3 : হ্যাঁ, এসএসডি একটি ভিন্ন জন্তু। এটি সম্ভবত ইউএসবি নয়, এসএটিএর মাধ্যমে সংযুক্ত হবে। আমি মনে করি যে ওপি কেবল ভুল ভাষায় কথা বলেছে এবং একটি ইউএসবি স্টিককে এসএসডি হিসাবে উল্লেখ করেছে। তবে আবার, ওপি থেকে আমরা আরও বিশদ না পেলে জানার উপায় নেই।
অযৌক্তিক জন

2
এই উত্তরটি প্রশ্নটি কীভাবে প্রণয়ন করা হয়েছিল তা স্পষ্টভাবে উপেক্ষা করে। প্রশ্নটি একটি বড় ফাইল সম্পর্কে স্পষ্টভাবে আলোচনা করে এবং অনুলিপি করে যে অনুলিপি একটি ম্যাংলেড ফাইলের ফলাফল দেয়।
zrajm

4
@Zrajm এটি সত্য। তবে আমার মতো লোকেরাও একই সমস্যায় ঝাঁপিয়ে পড়ে, এটি খুব সহায়ক।
পিথিকোস

কীভাবে এই ক্যাচিং আচরণটি অক্ষম করবেন?
আমিনু কানো

7

আমি যা করেছি তা স্থির করেছিলাম যে আনমাউন্ট করা, ড্রাইভ সরানো sudo modprobe ehci_hcdএবং টার্মিনালে চালানো । ড্রাইভ এবং agian সন্নিবেশ sudo modprobe ehci_hcdযখন আমি এ ড্রাইভের করা এবং ঘেউ 20 / এমবিএস আমি ভাগ হবে ভেবেছিলাম। আশা করি আমাকে প্রতিবারই এটি করতে হবে না ... তবে এটা খুব কঠিন নয় ...

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177235 তারা বাগটি ঠিক করেছে।


সিরিয়াসলি ?? সেই বাগ রিপোর্টটি ২০০ 2007 সালের ডিসেম্বর থেকে এবং উবুন্টু গুটিস 7..১০ এর উল্লেখ রয়েছে। (এফওয়াইআই: @ মার্কোসিপ্পি)
অযৌক্তিক জন জন

3
@irrational জন আমি উত্তরটি সরবরাহ করিনি, আমি কেবল এটি পরিষ্কার করে দিয়েছি। দ্বিতীয়ত কেবল কারণ হিসাবে একটি বাগ রিপোর্ট পুরানো, এর অর্থ এটি এখনও বৈধ নয়। এটা তোলে triaged হচ্ছে অনুযায়ী এই
মার্কো Ceppi

@ মারকোচিপি হ্যাঁ, আমি জানি আপনি কেবল সম্পাদিত। সে কারণেই আমি " এফওয়াইআই: " এর উপস্থাপনা করেছি। আমি যদি আপনি এটি সম্পাদিত আপনি (বা হয়তো পারে মূর্ত না ) আগ্রহী হতে। আমি চিন্তা করেছি যদি আপনি যত্ন না করেন তবে আপনি কেবল বিজ্ঞপ্তিটি এড়িয়ে যাবেন। পুরানো বাগের প্রতিবেদনের এখনও প্রাসঙ্গিকতা রয়েছে ... 4 বছর আগে এবং আমি মনে করি কমপক্ষে 8 (?) পরে প্রকাশিত হবে? পারফরম্যান্স বাগের জন্য? অবশ্যই, এটি সম্ভব হতে পারে তবে এটি আমি প্রথম দেখছি না। FWIW।
অযৌক্তিক জন

7

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


5

শুধু umountডিভাইস এটি ইতিমধ্যেই automounted করা হয়, এবং নিজ হাতে এটি মাউন্ট /mnt/foldername

আমার ক্ষেত্রে,

umount /media/usb0
mount /dev/sdb1 /mnt/sam

এর পরে এটি খুব দ্রুত মোকাবেলা হচ্ছে।


এটির rsyncপরিবর্তে cpকৌশলটি মনে হয় do
ইরফান

19
এটি আমার পরিস্থিতিতে কোনও পার্থক্য করেনি। এছাড়াও, এটি কেন কোনও তাত্পর্য তৈরি করার কথা বলে কিছু তত্ত্ব ছাড়াই এটি সত্যিই সমাধান নয় ।
লন্ডনব্রব

@ ইরফান না, আরএসসিএনসি খুব কমিয়ে দিচ্ছে ...
সার্জজাচ

3

এটি 2019 এবং আমার এখনও এই একই সমস্যা রয়েছে। তাই আমি অনুভব করেছি যে আমি একটি সমাধানের জন্য ইন্টারনেট অনুসন্ধান করি। আমি নিম্নলিখিত পৃষ্ঠাটি পেয়েছি যা এর মধ্যে একটি পরামর্শ দেয়: https://gist.github.com/2E0PGS/f63544f8abe69acc5caaa54f56efe52f

এটা বলে:

এটি আপনার জন্য সমস্যার সমাধান করে কিনা তা দেখার জন্য কনসোলে নিম্নলিখিত কমান্ডগুলি কার্যকর করুন। আপনার sudo suপ্রথমে প্রয়োজনীয় অনুমতি প্রয়োজন হতে পারে ।

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

যদি এটি কাজ করে তবে আপনি নিজের /etc/rc.localফাইলটির শেষে দুটি লাইন আটকে রিবুটগুলি জুড়ে এই পরিবর্তনটি স্থির রাখতে পারেন ।

আমার জন্য এটি নিম্নলিখিত প্রভাব ছিল:

কোনও USB ড্রাইভে বড় ফাইল অনুলিপি করার আগে সত্যিই দ্রুত শুরু হবে (60 এমবি / গুলি এর মতো) এবং ধীরে ধীরে ধীরে ধীরে (<10 মেগাবাইট / সে) হয়ে যায় যতক্ষণ না দেখে মনে হয় এটি কখনই শেষ হবে না।

এখন এটি আস্তে আস্তে শুরু হয় তবে দ্রুত এবং দ্রুত হয় এবং আগের চেয়ে দ্রুত শেষ হয়। সুতরাং এটি সমস্যার "সমাধান" বলে মনে হচ্ছে বা কমপক্ষে একটি ইতিবাচক প্রভাব ফেলবে।


1

আপনি যদি কোনও ইউএসবি ৩.০ এ স্যুইচ করেন তবে আপনি 1 এমবি / এস থেকে ডুবানো 5-8mb / s তে চলে যাবেন। আমি একটি 3.0 ইউএসবি পিসি এবং বাহ্যিক এইচডি তে স্যুইচ করেছি এবং পিছনে ফিরে তাকাতে পারি নি।


1

আপনি যখন / etc / mtab এ দেখেন, আপনি কি দেখতে পান যে ডিভাইসটি "ফ্লাশ" বিকল্পের সাথে মাউন্ট করা হয়েছে?

যদি তা হয় তবে এটি সমস্যার কারণ হতে পারে (এটি আমার পক্ষে ছিল)। কেবল ডিভাইসটিকে আনমাউন্ট করুন এবং এটিকে পুনরায় মাউন্ট করুন, এটি ডিফল্টরূপে সেট করা উচিত নয়।


ফ্লাশ বিকল্পটি ডিফল্টরূপে সেট করা আছে, এটি থামানোর কোনও উপায়?
বেন লুটজেন

@ বেন লুটজেনস - হ্যাঁ, আপনি নিজের নিজের / / etc / fstab এ প্রবেশ করতে পারেন যাতে ফ্লাশ বিকল্প নেই। প্রাসঙ্গিক ডিভাইসটি ইউইউডি খুঁজতে স্যুডো ব্লকিড ব্যবহার করুন এবং ইউডিইউড = "আপনার ডিভাইসটি এখানে উউইড করুন" / এমএনটি / <আপনার মাউন্ট পয়েন্টটি এখানে> uid = 1000, জিড = 1000, fmask = 0022, dmask = 0022 0 0 এর মতো একটি এন্ট্রি রাখুন। আপনি ব্যবহার করেন এমন সাধারণ ব্যবহারকারীর ইউনিড এবং গ্রুপিডের সাথে মেলে মেলে uid, gid পরিবর্তন করুন (যেমনটি আপনার পাসওয়ার্ড <আপনার ব্যবহারকারী> দ্বারা পাওয়া গেছে)।
ড্যানিশচেউস্কি

আমি যখন এটি করি, সমস্ত পরিবর্তনগুলি হ'ল আমি অনুলিপি করার জন্য আর কোনও অগ্রগতি বার পাব না এবং অনুলিপিটি কেবল তখনই শুরু হবে / শেষ হবে যখন আমি ডিভাইসটি আনমাউন্ট করার চেষ্টা করি এবং এটি আমাকে বলে যে "অপারেশন শেষ না হওয়া অবধি প্লাগ ইন করবেন না until "।
জেনি ও'রিলি

0

আমার ডাব্লুডি বহিরাগত ডিস্কে স্থানান্তর হার নিয়ে কিছু সমস্যা ছিল, উইন্ডোজ এসও-তে এটি খোলার পরে, আমি সর্বদা লিনাক্স ব্যবহার করতাম, তারপরে স্থানান্তর হারটি 1.5mb / s এর মতো ছিল যেখানে আমি বহিরাগত হার্ড ড্রাইভ চালিত dmesg আনমাউন্ট করতাম না বলছেন যে এসডিবি 1 এটি অপ্রয়োজনীয়ভাবে আনমাউন্টড ছিল, একটি fsck চালায়, যা কয়েকটি মেরামত করে এবং সেই 20 এমবি / এস ট্রান্সফার রেট পরে আবার এসডিএ থেকে বাহ্যিক ডিস্কে কপিঞ্জ করে নিলে। আপনার কাছে ডেটা থাকলে fsck সবসময়ই ঝুঁকিপূর্ণ তবে এটি আমার জন্য কাজ করেছিল, কোনও ডেটা ক্ষতি ছাড়াই।


-2

আমারও এই সমস্যা ছিল, তবে আমি সিপি কমান্ডটি ব্যবহার করি এবং আপনি আপনার ইউএসবি স্টিকটি সেকেন্ডে আপডেট করেন;

cp -r -u /home/user/Muziek/ /media/user/Audiousbsti
cp -r -u /home/user/Muziek/ /media/user/4F49-4A65/

আমি মনে করি এটি খুব দেরিতে উত্তর তবে এটি এখনও উন্মুক্ত।


-3

ঠিক আছে, তিন দিনের জন্য আমার একই সমস্যা ছিল এবং আমি কীভাবে আমার 1TB হার্ড ড্রাইভটি ব্যাকআপ করতে পেরেছিলাম তা হল CSSync ব্যবহার করে, আমি জানি যে এটি ব্যাক আপ করার জন্য ব্যবহৃত হয় তবে এটি কাজটি সম্পন্ন করে, এমনকি বড় ফাইলগুলি স্থানান্তর করার পরেও আমি এটি ব্যবহার করি সেই কাজটি কর আপনি যদি এটি কোনও জিইউআইয়ের সাথে ব্যবহার করতে চান তবে আমি গ্রিসিঙ্ক ইনস্টল করার পরামর্শ দিচ্ছি যা আরএসএনসি-র একটি গ্রাফিকাল সংস্করণ, যেহেতু টার্মিনালটিতে আরএসসিএনচ চলছে।

আশা করি এটি সাহায্য করেছে

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