অ্যান্ড্রয়েড ১২ FUSE পাসথ্রু সমর্থন করে, যা নিম্নস্তরের ফাইল সিস্টেমে সরাসরি অ্যাক্সেসের সমতুল্য পারফরম্যান্স অর্জনের জন্য FUSE ওভারহেড কমিয়ে আনে। FUSE পাসথ্রু android12-5.4 , android12-5.10 , এবং android-mainline (শুধুমাত্র পরীক্ষার জন্য) কার্নেলগুলোতে সমর্থিত, যার অর্থ হলো এই ফিচারের সমর্থন নির্ভর করে ডিভাইসটিতে ব্যবহৃত কার্নেল এবং ডিভাইসটিতে চলমান অ্যান্ড্রয়েডের সংস্করণের উপর।
অ্যান্ড্রয়েড ১১ থেকে অ্যান্ড্রয়েড ১২-এ আপগ্রেড করা ডিভাইসগুলো FUSE passthrough সমর্থন করতে পারে না, কারণ এই ডিভাইসগুলোর কার্নেল অপরিবর্তিত থাকে এবং FUSE passthrough-এর পরিবর্তনগুলোসহ আনুষ্ঠানিকভাবে আপগ্রেড করা কোনো কার্নেলে সেগুলোকে স্থানান্তর করা যায় না।
অ্যান্ড্রয়েড ১২ সহ লঞ্চ হওয়া ডিভাইসগুলো অফিসিয়াল কার্নেল ব্যবহার করলে FUSE পাসথ্রু সমর্থন করতে পারে। এই ধরনের ডিভাইসগুলোর জন্য, FUSE পাসথ্রু বাস্তবায়নকারী অ্যান্ড্রয়েড ফ্রেমওয়ার্ক কোডটি MediaProvider মেইনলাইন মডিউলে এমবেড করা থাকে, যা স্বয়ংক্রিয়ভাবে আপগ্রেড হয়। যে ডিভাইসগুলো MediaProvider-কে মেইনলাইন মডিউল হিসেবে বাস্তবায়ন করে না (উদাহরণস্বরূপ, অ্যান্ড্রয়েড গো ডিভাইস), সেগুলোও সর্বজনীনভাবে শেয়ার করা হলে MediaProvider-এর পরিবর্তনগুলো অ্যাক্সেস করতে পারে।
FUSE বনাম SDCardFS
ফাইল সিস্টেম ইন ইউজারস্পেস (FUSE) হলো এমন একটি ব্যবস্থা, যা FUSE ফাইল সিস্টেমে সম্পাদিত অপারেশনগুলোকে কার্নেল (FUSE ড্রাইভার) থেকে একটি ইউজারস্পেস প্রোগ্রামের (FUSE ডেমন) কাছে আউটসোর্স করার সুযোগ দেয়, যে প্রোগ্রামটি অপারেশনগুলো বাস্তবায়ন করে। অ্যান্ড্রয়েড ১১ SDCardFS-কে অপ্রচলিত ঘোষণা করে এবং স্টোরেজ এমুলেশনের জন্য FUSE-কে ডিফল্ট সমাধান হিসেবে চালু করে। এই পরিবর্তনের অংশ হিসেবে, অ্যান্ড্রয়েড ফাইল অ্যাক্সেস আটকানো, অতিরিক্ত নিরাপত্তা ও গোপনীয়তার বৈশিষ্ট্য প্রয়োগ করা এবং রানটাইমে ফাইল ম্যানিপুলেট করার জন্য নিজস্ব FUSE ডেমন তৈরি করে।
পেজ বা অ্যাট্রিবিউটের মতো ক্যাশেযোগ্য তথ্য নিয়ে কাজ করার ক্ষেত্রে FUSE ভালো পারফর্ম করলেও, এক্সটার্নাল স্টোরেজ অ্যাক্সেস করার সময় এটি পারফরম্যান্সে অবনতি ঘটায়, যা বিশেষ করে মাঝারি এবং নিম্ন-মানের ডিভাইসগুলোতে লক্ষণীয়। এই অবনতিগুলোর কারণ হলো FUSE ফাইল সিস্টেম বাস্তবায়নে সহযোগিতাকারী একাধিক কম্পোনেন্টের একটি শৃঙ্খল, এবং সেইসাথে FUSE ড্রাইভার ও FUSE ডেমন-এর মধ্যে যোগাযোগের ক্ষেত্রে কার্নেল স্পেস থেকে ইউজার স্পেসে একাধিকবার সুইচ করা (যা কার্নেলে সম্পূর্ণরূপে বাস্তবায়িত ও আরও হালকা নিম্নস্তরের ফাইল সিস্টেমে সরাসরি অ্যাক্সেসের তুলনায় ঘটে)।
এই রিগ্রেশনগুলো প্রশমিত করতে, অ্যাপগুলো ডেটা কপি করা কমাতে স্প্লাইসিং ব্যবহার করতে পারে এবং নিম্ন ফাইল সিস্টেম ফাইলগুলোতে সরাসরি অ্যাক্সেস পেতে ContentProvider API ব্যবহার করতে পারে। এই এবং অন্যান্য অপ্টিমাইজেশন থাকা সত্ত্বেও, নিম্ন ফাইল সিস্টেমে সরাসরি অ্যাক্সেসের তুলনায় FUSE ব্যবহার করার সময় রিড এবং রাইট অপারেশনে ব্যান্ডউইথ কমে যেতে পারে — বিশেষ করে র্যান্ডম রিড অপারেশনের ক্ষেত্রে, যেখানে কোনো ক্যাশিং বা রিড-অহেড সাহায্য করতে পারে না। এবং যে অ্যাপগুলো পুরোনো /sdcard/ পাথের মাধ্যমে সরাসরি স্টোরেজ অ্যাক্সেস করে, তারা পারফরম্যান্সে লক্ষণীয় ঘাটতি অনুভব করতে থাকে, বিশেষ করে IO-ইনটেনসিভ অপারেশন করার সময়।
SDcardFS ব্যবহারকারীর স্পেস অনুরোধ
কার্নেল থেকে ইউজার স্পেস কলটি সরিয়ে দেওয়ার মাধ্যমে SDcardFS ব্যবহার করে FUSE-এর স্টোরেজ এমুলেশন এবং পারমিশন চেকের গতি বাড়ানো যায়। ইউজারস্পেস রিকোয়েস্টগুলো এই পথ অনুসরণ করে: Userspace → VFS → sdcardfs → VFS → ext4 → Page cache/Storage।

চিত্র ১. SDcardFS ব্যবহারকারী স্থানের অনুরোধসমূহ
FUSE ব্যবহারকারী স্পেস অনুরোধ
FUSE প্রাথমিকভাবে স্টোরেজ এমুলেশন সক্ষম করতে এবং অ্যাপগুলিকে স্বচ্ছভাবে অভ্যন্তরীণ স্টোরেজ বা একটি বাহ্যিক এসডিকার্ড ব্যবহার করার সুযোগ দিতে ব্যবহৃত হত। FUSE ব্যবহারে কিছু অতিরিক্ত কাজ যুক্ত হয়, কারণ প্রতিটি ইউজারস্পেস অনুরোধ এই পথ অনুসরণ করে: ইউজারস্পেস → VFS → FUSE ড্রাইভার → FUSE ডেমন → VFS → ext4 → পেজ ক্যাশে/স্টোরেজ।

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

চিত্র ৩. FUSE অনুরোধ বনাম FUSE পাসথ্রু অনুরোধ
যখন কোনো অ্যাপ FUSE ফাইল সিস্টেম অ্যাক্সেস করে, তখন নিম্নলিখিত অপারেশনগুলো সংঘটিত হয়:
FUSE ড্রাইভার অনুরোধটি গ্রহণ করে এবং কিউতে যুক্ত করে, তারপর এটিকে
/dev/fuseফাইলের একটি নির্দিষ্ট সংযোগ ইনস্ট্যান্সের মাধ্যমে সেই FUSE ফাইল সিস্টেমটি পরিচালনাকারী FUSE ডেমন-এর কাছে উপস্থাপন করে, যে ফাইলটি FUSE ডেমন পড়তে পারে না।যখন FUSE ডেমন কোনো ফাইল খোলার জন্য অনুরোধ পায়, তখন এটি সিদ্ধান্ত নেয় যে সেই নির্দিষ্ট ফাইলটির জন্য FUSE পাসথ্রু উপলব্ধ থাকবে কি না। যদি এটি উপলব্ধ থাকে, তাহলে ডেমনটি:
এই অনুরোধটি সম্পর্কে FUSE ড্রাইভারকে অবহিত করে।
FUSE_DEV_IOC_PASSTHROUGH_OPENioctl ব্যবহার করে ফাইলটির জন্য FUSE পাসথ্রু সক্ষম করে, যা খোলা/dev/fuseএর ফাইল ডেসক্রিপ্টরের উপর অবশ্যই সম্পাদন করতে হবে।
ioctl প্যারামিটার হিসেবে একটি ডেটা স্ট্রাকচার গ্রহণ করে, যাতে নিম্নলিখিত বিষয়গুলো থাকে:
নিম্ন ফাইল সিস্টেম ফাইলের ফাইল ডেসক্রিপ্টর, যা পাসথ্রু ফিচারের লক্ষ্যবস্তু।
বর্তমানে প্রক্রিয়াধীন FUSE অনুরোধটির অনন্য শনাক্তকারী (অবশ্যই খোলা অথবা তৈরি ও খোলার অবস্থায় থাকতে হবে)।
অতিরিক্ত ক্ষেত্রসমূহ যেগুলো খালি রাখা যেতে পারে এবং ভবিষ্যতের বাস্তবায়নের জন্য রাখা হয়েছে।
যদি ioctl সফল হয়, তাহলে FUSE ডেমন খোলার অনুরোধটি সম্পন্ন করে, FUSE ড্রাইভার FUSE ডেমন-এর উত্তরটি গ্রহণ করে, এবং কার্নেলের ভেতরের FUSE ফাইলে নিম্নতর ফাইল সিস্টেম ফাইলের একটি রেফারেন্স যুক্ত করা হয়। যখন কোনো অ্যাপ একটি FUSE ফাইলে রিড/রাইট অপারেশনের জন্য অনুরোধ করে, তখন FUSE ড্রাইভার পরীক্ষা করে দেখে যে নিম্নতর ফাইল সিস্টেম ফাইলের রেফারেন্সটি উপলব্ধ আছে কি না।
যদি কোনো রেফারেন্স উপলব্ধ থাকে, তাহলে ড্রাইভারটি নিম্নস্থ ফাইল সিস্টেম ফাইলটিকে লক্ষ্য করে একই প্যারামিটারসহ একটি নতুন ভার্চুয়াল ফাইল সিস্টেম (VFS) অনুরোধ তৈরি করে।
যদি কোনো রেফারেন্স উপলব্ধ না থাকে, তাহলে ড্রাইভার অনুরোধটি FUSE ডেমন-এর কাছে পাঠিয়ে দেয়।
উপরোক্ত অপারেশনগুলো জেনেরিক ফাইলের ক্ষেত্রে রিড/রাইট ও রিড-ইটার/রাইট-ইটার এবং মেমোরি-ম্যাপড ফাইলের ক্ষেত্রে রিড/রাইট অপারেশনের জন্য ঘটে থাকে। কোনো নির্দিষ্ট ফাইলের জন্য FUSE পাসথ্রু ততক্ষণ পর্যন্ত বিদ্যমান থাকে, যতক্ষণ না সেই ফাইলটি বন্ধ করা হয়।
FUSE পাসথ্রু বাস্তবায়ন করুন
Android 12 চালিত ডিভাইসগুলিতে FUSE passthrough সক্রিয় করতে, টার্গেট ডিভাইসের $ANDROID_BUILD_TOP/device/…/device.mk ফাইলে নিম্নলিখিত লাইনগুলি যোগ করুন।
# Use FUSE passthrough
PRODUCT_PRODUCT_PROPERTIES += \
persist.sys.fuse.passthrough.enable=true
FUSE পাসথ্রু নিষ্ক্রিয় করতে, উপরের কনফিগারেশন পরিবর্তনটি বাদ দিন অথবা persist.sys.fuse.passthrough.enable কে false এ সেট করুন। আপনি যদি পূর্বে FUSE পাসথ্রু সক্রিয় করে থাকেন, তবে এটি নিষ্ক্রিয় করলে ডিভাইসটি FUSE পাসথ্রু ব্যবহার করতে পারবে না, কিন্তু ডিভাইসটি সচল থাকবে।
ডিভাইসটি ফ্ল্যাশ না করে FUSE পাসথ্রু চালু/বন্ধ করতে, ADB কমান্ড ব্যবহার করে সিস্টেম প্রপার্টি পরিবর্তন করুন। নিচে একটি উদাহরণ দেখানো হলো।
adb rootadb shell setprop persist.sys.fuse.passthrough.enable {true,false}adb reboot
অতিরিক্ত সাহায্যের জন্য, রেফারেন্স ইমপ্লিমেন্টেশনটি দেখুন।
FUSE পাসথ্রু যাচাই করুন
MediaProvider যে FUSE passthrough ব্যবহার করছে তা যাচাই করতে, ডিবাগিং বার্তাগুলির জন্য logcat পরীক্ষা করুন। উদাহরণস্বরূপ:
adb logcat FuseDaemon:V \*:S
--------- beginning of main
03-02 12:09:57.833 3499 3773 I FuseDaemon: Using FUSE passthrough
03-02 12:09:57.833 3499 3773 I FuseDaemon: Starting fuse... FuseDaemon: Using FUSE passthrough নিশ্চিত করে যে FUSE passthrough ব্যবহৃত হচ্ছে।
অ্যান্ড্রয়েড ১২ সিটিএস-এ CtsStorageTest অন্তর্ভুক্ত রয়েছে, যার মধ্যে এমন কিছু টেস্ট আছে যা FUSE passthrough ট্রিগার করে। টেস্টটি ম্যানুয়ালি চালানোর জন্য, নিচে দেখানো পদ্ধতি অনুযায়ী atest ব্যবহার করুন:
atest CtsStorageTest