"त्वरित निष्कासन" के बावजूद छोटे USB ड्राइव पर FAT टेबल लिखने में देरी

मैं देख रहा हूं कि एक छोटी-सी क्षमता वाले FAT (FAT12) -फॉर्मैटेड USB फ्लैश ड्राइव पर FAT को लिखने में देरी हो रही है, भले ही ड्राइव के लिए पॉलिसी "क्विक रिमूवल" पर सेट है। (मेरा मानना है कि इसका मतलब है SurpriseRemovalOKझंडा सेट है)। मैंने USB पर ड्राइव पर भेजी गई SCSI कमांड्स को कैप्चर किया है: फाइल ट्रंकेशन तुरंत होता है, पूरी फाइल (2 512-बाइट सेक्टर लंबी) उसके तुरंत बाद लिखी जाती है, लेकिन तब FAT से पहले 20-90 सेकंड की देरी होती है फ़ाइल लिखने को प्रतिबिंबित करने के लिए अद्यतन किया जाता है।

ड्राइव का आकार महत्वपूर्ण है। मैंने 15MB और उससे छोटे आकार के FAT फाइल सिस्टम पर समस्याओं का परीक्षण किया है और देखा है। 16 एमबी और ऊपर, लेखन में देरी नहीं हुई है। 16MB वह ब्रेकपाइंट है जिसे मैं विंडोज में ड्राइव को फॉर्मेट करते समय FAT12 और FAT16 का उपयोग करने के बीच देखता हूं। (नोट बाद में जोड़ा गया: लेकिन FAT12 / FAT16 ब्रेकप्वाइंट क्लस्टर की संख्या पर निर्भर है, न कि पूर्ण फाइल सिस्टम आकार पर)।

16MB और बड़े पर, विंडोज़ SCSI Prevent/Allow Medium Removalकमांड को लिखने से पहले भेजता है , यह पूछता है कि डिवाइस को हटाया नहीं गया है। USB स्टिक वास्तव में इन अनुरोधों पर विफलता लौटाता है (क्योंकि यह कोई निष्कासन की गारंटी नहीं दे सकता है), लेकिन विंडोज वैसे भी कोशिश करता है। 15MB और छोटे निशान कोई Prevent/Allow Medium Removal आदेश नहीं दिखाते हैं ।

(मैंने माइक्रोकंट्रोलर बोर्ड का उपयोग करते समय इस समस्या का पता लगाया जो पायथन कोड युक्त एक छोटे से FAT फाइल सिस्टम का समर्थन करता है। जब माइक्रोकंट्रोलर फाइल सिस्टम के लिए एक लिखने का पता लगाता है, तो यह लिखने के लिए थोड़ा इंतजार करता है और फिर स्वचालित रूप से नए लिखित पायथन कोड को पुनरारंभ करता है और चलाता है। लेकिन देरी से लिखने के कारण माइक्रोकंट्रोलर दूषित कोड या दूषित फाइल सिस्टम देख रहा था।)

"क्विक रिमूवल" सेट होने के बावजूद FAT को लिखने में इतनी देर क्यों हो रही है? मैं ड्राइव पर "इजेक्ट" करके राइट्स को बाध्य कर सकता हूं लेकिन यह "क्विक रिमूवल" के वादे को हरा देता है। अगर मैंने ड्राइव को जल्दी खींचा तो उसमें गलत FAT टेबल होगी। यह नीचे दिए गए स्क्रीन शॉट में "सुरक्षित रूप से निकालें हार्डवेयर" का उपयोग नहीं करने के बारे में विवरण देता है। क्या यह बग है या मैं कुछ भूल गया हूं? क्या सभी लेखों को बिना किसी मैनुअल "इजेक्ट" के तुरंत होने के लिए मजबूर करने का कोई तरीका है?

यहाँ एक Wireshark / USBPcap ट्रेस से एक pruned अर्क मुद्दा दिखा रहा है। मैं एक मौजूदा फ़ाइल को काट देता हूं और फिर उसकी एक नई प्रति लिखता हूं। मैंने टिप्पणियों के साथ जोड़ा है ###। USB ड्राइव पर अधिकतर राइट्स ट्रेस में लगभग 5 सेकंड लगते हैं, लेकिन अंतिम FAT राइट 26 सेकंड तक नहीं होता है।

No.    Time  Source       Destination  Protocol  Length  Info
    ### write directory entry to truncate file
13 5.225586    host         1.2.2        USBMS    58     SCSI: Write(10) LUN: 0x00 (LBA: 0x00000041, Len: 8)
14 5.225838    host         1.2.2        USB      4123   URB_BULK out
    ### write FAT entries to truncate file
16 5.230488    host         1.2.2        USBMS    58     SCSI: Write(10) LUN: 0x00 (LBA: 0x0000003b, Len: 1)
17 5.230707    host         1.2.2        USB      539    URB_BULK out
19 5.235110    host         1.2.2        USBMS    58     SCSI: Write(10) LUN: 0x00 (LBA: 0x0000003e, Len: 1)
20 5.235329    host         1.2.2        USB      539    URB_BULK out
    ### write directory entry for 
22 5.252672    host         1.2.2        USBMS    58     SCSI: Write(10) LUN: 0x00 (LBA: 0x00000041, Len: 8)
23 5.252825    host         1.2.2        USB      4123   URB_BULK out
    ### write out file data (2 sectors of 512 bytes)
25 5.257416    host         1.2.2        USBMS    58     SCSI: Write(10) LUN: 0x00 (LBA: 0x000000c1, Len: 2)
26 5.257572    host         1.2.2        USB      1051   URB_BULK out
    ### 20 second delay
    ### finally, write FAT entries to indicate used sectors
79 26.559964      host      1.2.2        USBMS    58     SCSI: Write(10) LUN: 0x00 (LBA: 0x0000003b, Len: 1)
80 26.560191      host      1.2.2        USB      539    URB_BULK out
82 26.560834      host      1.2.2        USBMS    58     SCSI: Write(10) LUN: 0x00 (LBA: 0x0000003e, Len: 1)
83 26.560936      host      1.2.2        USB      539    URB_BULK out

मैंने एक नियमित फ्लैश ड्राइव का उपयोग करके इस तरह के निशान उत्पन्न किए हैं और एक माइक्रोकंट्रोलर बोर्ड के साथ भी जो विंडोज 7 और विंडोज़ 10 दोनों पर एक छोटे यूएसबी एमएससी ड्राइव का अनुकरण करता है।

बस स्पष्ट होने के लिए, यह एक FAT12- स्वरूपित ड्राइव है, जिसे विंडोज प्रारूपण टूल में "FAT" कहा जाता है।

windows usb-flash-drive fat16

— डैन हैल्बर्ट
स्रोत

क्या आप अभी उत्सुक हैं? या आप एक ऐसे परिदृश्य का सामना कर रहे हैं जहाँ आपको FAT16 फाइलसिस्टम का उपयोग करना आवश्यक है?

— मैं कहता हूं कि मोनिका

मैं एक माइक्रोकंट्रोलर बोर्ड (Adafruit F0 M0 और संबंधित) को MicroPython (सर्किटपाइथन) का एक संस्करण चलाने में मदद कर रहा हूं। इसमें एक छोटा FAT फाइल सिस्टम है जिसमें पायथन कोड है। एक सुविधा के रूप में, बोर्ड को ऑटो-रीसेट और रन main.pyया इसी तरह की फ़ाइलों के लिए सेट किया जाता है जब यह पता लगाता है कि फ़ाइल लिखी गई है। यह लिखने के लिए थोड़े समय के लिए देरी करता है, लेकिन सेकंड के दसियों के लिए नहीं। हम इस ऑटो-रिस्टार्ट को डिसेबल कर सकते हैं, लेकिन यह सुनिश्चित करने के लिए ड्राइव को "इजेक्ट" करना आवश्यक है कि यह सुनिश्चित हो कि राइट समय पर पूरा हो जाए। उपयोगकर्ता को एक बेदखल करना आवश्यक है एक उपद्रव; हम उससे बचना चाहते हैं।

— डैन हैल्बर्ट

कृपया अपने प्रश्न के आरंभ में संपादन पर विचार करें। यह अच्छा पृष्ठभूमि संदर्भ है।

— मैं कहता हूं कि मोनिका

अच्छा सुझाव। किया हुआ।

— डैन हैल्बर्ट

मुझे वास्तविक Windows ड्राइवर कोड मिल सकता है जो समस्या का कारण बन रहा है।

MS नमूना ड्राइवर कोड के एक पैकेज में FAT फाइलसिस्टम चालक को शामिल करने के लिए होता है। उस ड्राइवर में कई जगह होती हैं, जहाँ अगर फाइलसिस्टम FAT12 है, तो ड्राइवर कुछ करने की जहमत नहीं उठाएगा जैसे कि गंदा सा सेट (शायद FAT12 के लिए कोई नहीं है) या FAT डेटा को फ्लश करें।

https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys/fastfat/verfysup.c#L774 https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys /fastfat/cachesup.c#L1212 और शायद सबसे गंभीर: https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys/fastfat/cleann.c#L1101

अंतिम लिंक में cleanup.c, अगर फ़ाइल सिस्टम FAT12 है, तो FAT को फ्लश नहीं किया जाता है। मुझे लगता है कि यह मेरे द्वारा देखे गए व्यवहार के कारण हो सकता है:

    //
    //  If that worked ok,  then see if we should flush the FAT as well.
    //

    if (NT_SUCCESS(Status) && Fcb && !FatIsFat12( Vcb) && 
        FlagOn( Fcb->FcbState, FCB_STATE_FLUSH_FAT)) {

        Status = FatFlushFat( IrpContext, Vcb);

Microsoft को Windows प्रतिक्रिया हब में https://aka.ms/btvdog (विशेष URL जो फ़ीडबैक हब में खुलता है) पर रिपोर्ट किया गया।

— डैन हैल्बर्ट
स्रोत