Файловая система - ext4: суперблок, повреждающий приложение

Question

Я нашел много ссылок, но почти все указывают на причину, а не на причину.

Я создал 7GB раздел ext4 на SD-карте, подключенной через USB-ридер к ПК. У меня есть приложение, которое пишет 10488576 байт в указанный раздел (/dev/sdc2). После запуска приложения файловая система выглядит поврежденной:

#fsck.ext4 -v /dev/sdc2
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear<y>? no
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/sdc2

/dev/sdc2: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdc2: ********** WARNING: Filesystem still has errors **********



#dumpe2fs /dev/sdc2
dumpe2fs 1.42.8 (20-Jun-2013)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc2
Couldn't find valid filesystem superblock.

Приложение просто использует что-то вроде ниже (я не могу опубликовать точный код):

    char *write_buf; //declared in header
    write_buf = (char *) malloc(size) // where size = 10488576. This allocation is happening in function a() called from main
    char *buf; // declared locally in function b()
    buf = write_buf; // in function b()
    write(fd,buf,size); // in function b()

Размер блока файловой системы составляет 4 КБ. Резервный суперблок по номерам 32768, 98304,163840,229376, 294912,819200, 884736,1605632 Дайте мне знать, если потребуется дополнительная информация. Мне нужно понять, что может вызвать это повреждение, потому что я очень уверен, что что-то не так с кодом приложения.

EDIT: Я вижу, что основной суперблок начинается с 0, а вызов lseek() перед write() также делает SEEK_SET до 0, что переписало бы информацию о суперблоке. Я собираюсь попробовать Lseek далеко от суперблока, прежде чем write(),

EDIT Я исправил это, выполнив то, что упомянул выше. Согласно dumpe2fs o/p у меня было ниже для группы 0:

Group 0: (Blocks 0-32767)
  Checksum 0x8bba, unused inodes 8069
  Primary superblock at 0, Group descriptors at 1-1
  Reserved GDT blocks at 2-474
  Block bitmap at 475 (+475), Inode bitmap at 491 (+491)
  Inode table at 507-1011 (+507)
  24175 free blocks, 8069 free inodes, 2 directories, 8069 unused inodes
  Free blocks: 8593-32767
  Free inodes: 12-8080

Поэтому, прежде чем писать, я сделал поиск 8593*4096 . Теперь файловая система не повреждена.

Answer 1

Я исправил это, сделав, как я упоминал выше. Согласно dumpe2fs o/p у меня было ниже для группы 0:

Group 0: (Blocks 0-32767)
  Checksum 0x8bba, unused inodes 8069
  Primary superblock at 0, Group descriptors at 1-1
  Reserved GDT blocks at 2-474
  Block bitmap at 475 (+475), Inode bitmap at 491 (+491)
  Inode table at 507-1011 (+507)
  24175 free blocks, 8069 free inodes, 2 directories, 8069 unused inodes
  Free blocks: 8593-32767
  Free inodes: 12-8080

Поэтому, прежде чем писать, я сделал lseek до 8593*4096. Теперь файловая система не повреждена.