کیا لینکس بجلی کی بندش کی صورت میں ترتیب وار فائل لکھنے کا وعدہ کرتا ہے؟

بجلی کی ناکامیوں کے دوران فائل لکھنے کے استحکام کو سمجھنا

تصور کریں کہ آپ ایک فائل میں ڈیٹا کے دو اہم ٹکڑے لکھ رہے ہیں، اور اچانک بجلی چلی گئی۔ کیا Linux یا آپ کا منتخب کردہ فائل سسٹم اس بات کو یقینی بنائے گا کہ آپ کی دوسری تحریر اسٹوریج میں ظاہر نہیں ہوگی جب تک کہ پہلی تحریر مکمل نہ ہو؟ یہ ایک ایسا سوال ہے جسے بہت سے ڈویلپرز تب تک نظر انداز کر دیتے ہیں جب تک کہ تباہی نہ ہو۔ 🛑

ڈیٹا کی سالمیت کو سنبھالتے وقت فائل کی پائیداری بہت اہم ہوتی ہے، خاص طور پر جب بجلی کی ناکامی یا کریش ہوتے ہیں۔ POSIX-compliant سسٹم یا ext4 جیسے عام فائل سسٹمز کے ساتھ کام کرتے وقت یہ سوال اور بھی دباؤ بن جاتا ہے۔ کیا تحریریں ترتیب وار اور جوہری ہونے کی ضمانت ہیں، یا آپ کو اضافی احتیاط کی ضرورت ہے؟

مثال کے طور پر، دو غیر اوورلیپنگ حصوں میں ایک فائل میں لاگز یا ساختی ڈیٹا لکھنے والے بڑے ایپلیکیشن پر غور کریں۔ واضح ضمانتوں کے بغیر، اس بات کا خطرہ ہے کہ دوسری تحریر کا کچھ حصہ ڈسک میں داخل ہو جائے، جس سے فائل متضاد حالت میں رہ جائے۔ یہ خراب ڈیٹا بیس، گمشدہ لین دین، یا نامکمل ریکارڈز کا باعث بن سکتا ہے۔ 😓

یہ مضمون دریافت کرتا ہے کہ آیا POSIX، Linux، یا جدید فائل سسٹم جیسے ext4 گارنٹی فائل لکھنے کی پائیداری اور آرڈرنگ۔ ہم اس بات کا بھی تعین کریں گے کہ آیا fsync() یا fdatasync() کو تحریروں کے درمیان استعمال کرنا ڈیٹا کی عدم مطابقت کو روکنے کا واحد قابل اعتماد حل ہے۔

فائل لکھنے کی پائیداری کو سمجھنا اور ڈیٹا کی مستقل مزاجی کو یقینی بنانا

پہلے پیش کیے گئے اسکرپٹس میں، ہم نے لینکس فائل رائٹ میں پائیداری کی ضمانت کے مسئلے کو حل کیا جب غیر متوقع واقعات، جیسے کہ بجلی کی خرابی، واقع ہوتی ہے۔ توجہ اس بات کو یقینی بنانے پر تھی کہ ڈیٹا کا دوسرا بلاک، ڈیٹا2سٹوریج پر برقرار نہیں رہے گا جب تک کہ پہلا بلاک نہ ہو، ڈیٹا 1، پہلے ہی مکمل طور پر لکھا گیا تھا۔ حل احتیاط سے منتخب کردہ سسٹم کالوں کے مجموعے پر انحصار کرتا ہے، جیسے لکھنا اور fsync، اور فائل سسٹم کے طرز عمل۔ سب سے پہلے اسکرپٹ کا استعمال کیا گیا۔ fsync دو ترتیب وار تحریروں کے درمیان اس بات کی گارنٹی کے لیے کہ ڈیٹا 1 کو ڈیٹا2 لکھنے کے لیے آگے بڑھنے سے پہلے ڈسک پر فلش کیا جاتا ہے۔ یہ ڈیٹا کی سالمیت کو یقینی بناتا ہے، یہاں تک کہ اگر سسٹم پہلی تحریر کے بعد کریش ہو جائے۔

آئیے اسے مزید توڑتے ہیں: لکھنا فنکشن فائل پوائنٹر میں ترمیم کیے بغیر فائل کے اندر ایک مخصوص آفسیٹ کو لکھتا ہے۔ یہ خاص طور پر نان اوور لیپنگ تحریروں کے لیے مفید ہے، جیسا کہ یہاں دکھایا گیا ہے، جہاں دو ڈیٹا بلاکس کو الگ الگ آفسیٹس کے لیے لکھا جاتا ہے۔ واضح طور پر استعمال کرنے سے fsync پہلی تحریر کے بعد، ہم آپریٹنگ سسٹم کو فائل کے بفر شدہ مواد کو ڈسک پر فلش کرنے کے لیے مجبور کرتے ہیں، مستقل کو یقینی بناتے ہوئے۔ fsync کے بغیر، ڈیٹا میموری میں رہ سکتا ہے، بجلی کی ناکامی کے دوران نقصان کا خطرہ۔ ایک اہم لاگ انٹری لکھنے یا ڈیٹا بیس کا حصہ محفوظ کرنے کا تصور کریں — اگر پہلا حصہ غائب ہو جائے تو ڈیٹا متضاد ہو جاتا ہے۔ 😓

دوسرے اسکرپٹ میں، ہم نے کے استعمال کی کھوج کی۔ O_SYNC میں پرچم کھلا سسٹم کال. اس فلیگ کے فعال ہونے کے ساتھ، ہر تحریری آپریشن فوری طور پر ڈیٹا کو ذخیرہ کرنے کے لیے فلش کرتا ہے، جس سے دستی کی ضرورت کو دور کیا جاتا ہے۔ fsync کالز یہ کوڈ کو آسان بناتا ہے جبکہ اب بھی پائیداری کی ضمانت کو یقینی بناتا ہے۔ تاہم، ایک تجارت ہے: O_SYNC کا استعمال کارکردگی کا جرمانہ متعارف کراتا ہے کیونکہ ہم وقت ساز تحریریں بفر شدہ تحریروں کے مقابلے میں زیادہ وقت لیتی ہیں۔ یہ نقطہ نظر ان نظاموں کے لیے مثالی ہے جہاں قابل اعتماد کارکردگی کے خدشات سے کہیں زیادہ ہے، جیسے کہ مالیاتی نظام یا ریئل ٹائم ڈیٹا لاگنگ۔ مثال کے طور پر، اگر آپ سینسر ڈیٹا یا ٹرانزیکشن لاگز کو محفوظ کر رہے ہیں، تو آپ کو ہر تحریر کو بالکل قابل اعتماد ہونے کی ضرورت ہے۔ 🚀

Python میں لکھے گئے یونٹ ٹیسٹ اسکرپٹ نے C پروگرام کو چلانے کے بعد فائل کے مواد کو چیک کرکے ان حلوں کی توثیق کی۔ اس نے یقینی بنایا کہ ڈیٹا 1 اور ڈیٹا 2 دونوں کو توقع کے مطابق لکھا گیا تھا۔ یہ قدم مختلف حالات میں فائل آپریشنز کی جانچ کی اہمیت کو اجاگر کرتا ہے۔ اگر آپ پروڈکشن سرور پر اسی طرح کا حل لگانا چاہتے ہیں تو، آپ کی تحریروں کی سالمیت کی تصدیق کے لیے یونٹ ٹیسٹ اہم ہوں گے۔ مضبوط کوڈنگ کے طریقوں جیسے fsync کے استعمال کو ٹیسٹ کے ذریعے توثیق کے ساتھ جوڑ کر، آپ اعتماد کے ساتھ POSIX-مطابق سسٹمز پر اپنی فائل کے لکھنے کی پائیداری اور مستقل مزاجی کو یقینی بنا سکتے ہیں۔

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
int main() {
    int fd;
    const char *path = "example_file.txt";
    const char *data1 = "First write block";
    const char *data2 = "Second write block";
    size_t size1 = strlen(data1);
    size_t size2 = strlen(data2);
    off_t offset1 = 0;
    off_t offset2 = size1;

    // Open the file
    fd = open(path, O_RDWR | O_CREAT, 0666);
    if (fd == -1) {
        perror("Failed to open file");
        return 1;
    }

    // Perform first write
    if (pwrite(fd, data1, size1, offset1) == -1) {
        perror("Failed to write data1");
        close(fd);
        return 1;
    }

    // Use fsync to flush the first write to disk
    if (fsync(fd) == -1) {
        perror("fsync failed after data1");
        close(fd);
        return 1;
    }

    // Perform second write
    if (pwrite(fd, data2, size2, offset2) == -1) {
        perror("Failed to write data2");
        close(fd);
        return 1;
    }

    // Final fsync to ensure data2 is flushed
    if (fsync(fd) == -1) {
        perror("fsync failed after data2");
        close(fd);
        return 1;
    }

    // Close the file
    if (close(fd) == -1) {
        perror("Failed to close file");
        return 1;
    }

    printf("Writes completed and synced successfully.\n");
    return 0;
}

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
int main() {
    int fd;
    const char *path = "simple_ordered_file.txt";
    const char *data1 = "Data block 1";
    const char *data2 = "Data block 2";
    size_t size1 = strlen(data1);
    size_t size2 = strlen(data2);

    // Open file with O_SYNC for synchronous writes
    fd = open(path, O_RDWR | O_CREAT | O_SYNC, 0666);
    if (fd == -1) {
        perror("Open failed");
        return 1;
    }

    // Write first data
    if (write(fd, data1, size1) == -1) {
        perror("Write data1 failed");
        close(fd);
        return 1;
    }

    // Write second data
    if (write(fd, data2, size2) == -1) {
        perror("Write data2 failed");
        close(fd);
        return 1;
    }

    // Close file
    close(fd);
    printf("Writes completed with O_SYNC.\n");
    return 0;
}

import os
def validate_file_content(path):
    try:
        with open(path, 'r') as f:
            content = f.read()
        assert "Data block 1" in content
        assert "Data block 2" in content
        print("Test passed: Both writes are present.")
    except AssertionError:
        print("Test failed: Writes are inconsistent.")
    except Exception as e:
        print(f"Error: {e}")

# File validation after running a C program
validate_file_content("simple_ordered_file.txt")

لینکس میں ڈیٹا کی مستقل مزاجی کو یقینی بنانا: جرنلنگ اور بفرڈ رائٹ

تفہیم کا ایک اہم پہلو استحکام کی ضمانت دیتا ہے لینکس فائل سسٹم میں جیسے ext4 جرنلنگ کا کردار ہے۔ جرنلنگ فائل سسٹمز غیر متوقع واقعات کے دوران بدعنوانی کو روکنے میں مدد کرتے ہیں جیسے بجلی کی ناکامی، تبدیلیوں کے لاگ (یا جرنل) کو برقرار رکھنے سے پہلے وہ مرکزی اسٹوریج کے لیے پرعزم ہیں۔ جریدہ اس بات کو یقینی بناتا ہے کہ آپ کے ڈیٹا کو مستقل رکھتے ہوئے نامکمل کارروائیوں کو واپس کر دیا جائے۔ تاہم، جرنلنگ فطری طور پر کالنگ جیسی اضافی احتیاط کے بغیر آرڈر شدہ تحریروں کی ضمانت نہیں دیتی ہے۔ fsync. ہماری مثال میں، جب جرنلنگ اس بات کو یقینی بنا سکتی ہے کہ فائل خراب نہ ہو، اس کے کچھ حصے ڈیٹا2 پہلے بھی برقرار رہ سکتا ہے۔ ڈیٹا 1.

ایک اور غور یہ ہے کہ لینکس بفر فائل کیسے لکھتا ہے۔ جب آپ استعمال کرتے ہیں۔ pwrite یا write، ڈیٹا اکثر میموری بفر پر لکھا جاتا ہے، براہ راست ڈسک پر نہیں۔ یہ بفرنگ کارکردگی کو بہتر بناتی ہے لیکن ایک خطرہ پیدا کرتی ہے جہاں بفر فلش ہونے سے پہلے سسٹم کریش ہونے کی صورت میں ڈیٹا کا نقصان ہو سکتا ہے۔ کال کرنا fsync یا کے ساتھ فائل کو کھولنا O_SYNC جھنڈا اس بات کو یقینی بناتا ہے کہ بفر شدہ ڈیٹا کو محفوظ طریقے سے ڈسک پر فلش کیا جائے، تضادات کو روکا جائے۔ ان اقدامات کے بغیر، ڈیٹا جزوی طور پر لکھا ہوا ظاہر ہو سکتا ہے، خاص طور پر بجلی کی ناکامی کے معاملات میں۔ ⚡

بڑی فائلوں یا اہم سسٹمز کے ساتھ کام کرنے والے ڈویلپرز کے لیے، پائیداری کو ذہن میں رکھتے ہوئے پروگراموں کو ڈیزائن کرنا ضروری ہے۔ مثال کے طور پر، تصور کریں کہ ایک ایئر لائن ریزرویشن سسٹم سیٹ کی دستیابی کا ڈیٹا لکھ رہا ہے۔ اگر پہلا بلاک جس میں پرواز کی تفصیلات کی نشاندہی ہوتی ہے وہ پوری طرح سے نہیں لکھی جاتی ہے اور دوسرا بلاک برقرار رہتا ہے، تو یہ ڈیٹا کرپٹ یا ڈبل ​​بکنگ کا باعث بن سکتا ہے۔ استعمال کرنا fsync یا fdatasync نازک مراحل میں ان خرابیوں سے بچتا ہے۔ بھروسے کو یقینی بنانے کے لیے ہمیشہ حقیقی ناکامی کے نقوش کے تحت رویے کی جانچ کریں۔ 😊