S3 फ़ाइलें हैं, लेकिन फ़ाइलसिस्टम नहीं

S3 क्या है (और क्या नहीं है)

• व्यापक सहमति: S3 एक object store / key–value store है, पारंपरिक filesystem नहीं।
• मूल मॉडल: keys → objects का समतल mapping; keys अपारदर्शी strings होती हैं, operations whole-object GET/PUT/DELETE होती हैं।
• POSIX-शैली semantics (inodes, directories as first-class objects, partial writes, atomic renames) जानबूझकर अनुपस्थित हैं।
• कुछ लोग तर्क देते हैं कि व्यापक अर्थ में S3 फिर भी “filesystem का एक प्रकार” है (“files को manage करने वाली system”), जबकि दूसरे मानते हैं कि इससे शब्द का अर्थ धुंधला होता है और उपयोगकर्ताओं को गलत assumptions मिलती हैं।

“Folders” और Path Semantics

• S3 में असली directories नहीं होतीं। console में “folders” key prefixes पर UI sugar हैं, और कभी-कभी 0-byte “marker” objects से implement की जाती हैं।
• परिणाम:
  • आप dir, dir/file, dir//file जैसे keys एक साथ रख सकते हैं; S3 के लिए slashes विशेष नहीं हैं।
  • आखिरी object हटते ही खाली “folders” गायब हो जाते हैं।
  • किसी “folder” का नाम बदलने के लिए उस prefix वाले हर object को copy और delete करना पड़ता है (object की संख्या के अनुसार O(number of objects) और non-atomic)।

Operations, Performance, and Listing

• इन-प्लेस modification या append नहीं होता; बदली हुई सामग्री को फिर से upload करना पड़ता है या ऊपरी layer पर chunking करनी पड़ती है।
• Copy और rename copy+delete के रूप में implement होते हैं, जिनकी लागत और latency object size के साथ बढ़ती है।
• Listing एक बड़ा semantic और performance अंतर है:
  • S3 prefix के आधार पर lexicographic order में list करता है और pagination सपोर्ट करता है; prefix-based scans और partitioning के लिए बहुत efficient हो सकता है।
  • Recursive, POSIX-शैली directory walks धीमे होते हैं और कई sequential list calls मांगते हैं; बड़े buckets को delete या empty करना महंगा और जटिल हो सकता है।

Databases और S3 पर Filesystem Layers

• पारंपरिक databases को सीधे S3 पर चलाना आम तौर पर खराब fit माना जाता है: latency, partial writes का अभाव, और atomic “write if not exists” नहीं।
• सफल पैटर्न:
  • ऐसे systems जो append-only हों या files को immutable parts की तरह treat करें (जैसे analytical engines, Delta/Iceberg/Hudi जैसे table formats)।
  • ऐसी architectures जो S3 को data plane की तरह use करें, साथ में अलग, strongly consistent metadata/index layer हो (जैसे S3 पर WAL के साथ और local caches वाले DBs, या external metadata services)।
  • FUSE और VFS layers (जैसे rclone, custom filesystems) जो locally caching, chunking, और metadata को कहीं और manage करके POSIX emulation करती हैं—उपयोगी लेकिन जटिल और leaky।

Durability, Cost, और Alternatives

• S3 की durability की बहुत प्रशंसा की जाती है; इसे industry-leading बताया जाता है, heavy use of checksums और replication के साथ, हालांकि third-party, Jepsen-style validation का उल्लेख नहीं किया गया।
• S3 को आम तौर पर बड़े, cold datasets के लिए सस्ता माना जाता है; कुछ लोग कहते हैं कि इससे भी सस्ते object stores मौजूद हैं, लेकिन उनमें reliability या features की कीमत चुकानी पड़ सकती है।
• सही filesystem semantics और कम latency के लिए commenters EBS/EFS/FSx या on-prem filesystems की ओर इशारा करते हैं; “S3-like but simpler” local setups के लिए object-storage servers या custom layers सुझाई जाती हैं।