Boylan, Ross | 19 Nov 01:35 2015
Picon

recovering corrupt file system

Any recommendations for tools to diagnose and recover problems on an ext4 file system?

In particular:
root <at> jessie01:~# mount -o ro /dev/markov02/root /mnt/markov02
mount: wrong fs type, bad option, bad superblock on /dev/mapper/markov02-root,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
and e2fsck says
root <at> jessie01:~# e2fsck /dev/markov02/root
e2fsck 1.42.12 (29-Aug-2014)
/dev/markov02/root: recovering journal
Superblock needs_recovery flag is clear, but journal has data.

markov02/root is an LVM volume, built on partitions from 2 disks in a virtual machine.  The initial symptom
was that the VM the disks were in originally would only get as far as busybox when it started.  However, I
think the filesystem was OK even after that, since it was visible in busybox and in another VM.  I think
virt-manager might have overwritten on of the disks because I left "allocate entire disk now" checked
when I moved one of the disks between machines.

I'm making copies of the virtual disks now.
Ross Boylan
gagan chhabra | 28 Sep 09:07 2015
Picon

parse raw image to read block group desc table!

Hi,

I am writing a piece of code to open a raw image file of a virtual machine which has ubuntu installed in it. The virtual disk is formatted using MBR partitioning method and has 3 primary and 1 extended partition.

I want to open up that file and read the block group descriptor table and inode table for each partition. I have written some lines of code and successfully able to read the partition entries and the superblock of each partition.

But now I am stuck and unable to read  block group descriptor table and inode table. Shall I post my code here? Any suggestion or resource would be of great help.

Thanks,
Gagan
Mob: +91 97049 28427

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Tomas Pospisek | 25 May 23:59 2015
Picon

fsck failing to notice that the block device was pulled out from under it?

Hello,

tl;dr: it seems like fsck fails to notice when the block device
disappears from under it.

I have the following setup:

* external USB disk
* a partition with LUKS in it
* ext4 filesystem inside the LUKS block device

While doing backups to it I noticed that after some time backups would
fail with an error (failed to write, ).

In the following log I'm attaching the disk, enabling LUKS and mounting
the disk and then starting the backup, which will fail after a while:

May 25 11:39:18 hier kernel: [76241.727367] usb 4-1.1: new high-speed
USB device number 6 using ehci-pci
May 25 11:39:19 hier kernel: [76241.881892] usb 4-1.1: New USB device
found, idVendor=0bc2, idProduct=3320
May 25 11:39:19 hier kernel: [76241.881902] usb 4-1.1: New USB device
strings: Mfr=2, Product=3, SerialNumber=1
May 25 11:39:19 hier kernel: [76241.881907] usb 4-1.1: Product:
Expansion Desk
May 25 11:39:19 hier kernel: [76241.881911] usb 4-1.1: Manufacturer: Seagate
May 25 11:39:19 hier kernel: [76241.881915] usb 4-1.1: SerialNumber:
NA4JDN4N
May 25 11:39:19 hier kernel: [76241.882652] usb-storage 4-1.1:1.0: USB
Mass Storage device detected
May 25 11:39:19 hier kernel: [76241.883007] scsi7 : usb-storage 4-1.1:1.0
May 25 11:39:20 hier kernel: [76242.907527] usb 4-1.1: USB disconnect,
device number 6
May 25 11:39:30 hier kernel: [76252.987833] usb 4-1.1: new high-speed
USB device number 7 using ehci-pci
May 25 11:39:30 hier kernel: [76253.142659] usb 4-1.1: New USB device
found, idVendor=0bc2, idProduct=3320
May 25 11:39:30 hier kernel: [76253.142669] usb 4-1.1: New USB device
strings: Mfr=2, Product=3, SerialNumber=1
May 25 11:39:30 hier kernel: [76253.142674] usb 4-1.1: Product:
Expansion Desk
May 25 11:39:30 hier kernel: [76253.142678] usb 4-1.1: Manufacturer: Seagate
May 25 11:39:30 hier kernel: [76253.142681] usb 4-1.1: SerialNumber:
NA4JDN4N
May 25 11:39:30 hier kernel: [76253.143465] usb-storage 4-1.1:1.0: USB
Mass Storage device detected
May 25 11:39:30 hier kernel: [76253.144285] scsi8 : usb-storage 4-1.1:1.0
May 25 11:39:31 hier kernel: [76254.144816] scsi 8:0:0:0: Direct-Access
    Seagate  Expansion Desk   070B PQ: 0 ANSI: 6
May 25 11:39:31 hier kernel: [76254.145528] sd 8:0:0:0: Attached scsi
generic sg1 type 0
May 25 11:39:31 hier kernel: [76254.146193] sd 8:0:0:0: [sdb] 732566645
4096-byte logical blocks: (3.00 TB/2.72 TiB)
May 25 11:39:31 hier kernel: [76254.147465] sd 8:0:0:0: [sdb] Write
Protect is off
May 25 11:39:31 hier kernel: [76254.147477] sd 8:0:0:0: [sdb] Mode
Sense: 43 00 00 00
May 25 11:39:31 hier kernel: [76254.148657] sd 8:0:0:0: [sdb] Write
cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 25 11:39:31 hier kernel: [76254.149907] sd 8:0:0:0: [sdb] 732566645
4096-byte logical blocks: (3.00 TB/2.72 TiB)
May 25 11:39:31 hier kernel: [76254.179482]  sdb: sdb1 sdb2
May 25 11:39:31 hier kernel: [76254.181592] sd 8:0:0:0: [sdb] 732566645
4096-byte logical blocks: (3.00 TB/2.72 TiB)
May 25 11:39:31 hier kernel: [76254.184058] sd 8:0:0:0: [sdb] Attached
SCSI disk
May 25 11:39:40 hier kernel: [76263.066639] device-mapper: uevent:
version 1.0.3
May 25 11:39:40 hier kernel: [76263.066841] device-mapper: ioctl:
4.27.0-ioctl (2013-10-30) initialised: dm-devel <at> redhat.com
May 25 11:39:40 hier kernel: [76263.706456] NET: Registered protocol
family 38
May 25 11:39:41 hier kernel: [76263.976836] sha256_ssse3: Using AVX
optimized SHA-256 implementation
May 25 11:39:45 hier kernel: [76268.130879] EXT4-fs (dm-0): mounted
filesystem with ordered data mode. Opts: (null)
May 25 12:39:32 hier kernel: [79854.051465] usb 4-1.1: USB disconnect,
device number 7
May 25 12:39:32 hier kernel: [79854.052460] sd 8:0:0:0: [sdb]
Synchronizing SCSI cache
May 25 12:39:32 hier kernel: [79854.052634] sd 8:0:0:0: [sdb]
May 25 12:39:32 hier kernel: [79854.052636] Result:
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
May 25 12:39:32 hier kernel: [79854.250864] usb 4-1.1: new high-speed
USB device number 8 using ehci-pci
May 25 12:39:32 hier kernel: [79854.405885] usb 4-1.1: New USB device
found, idVendor=0bc2, idProduct=3320
May 25 12:39:32 hier kernel: [79854.405895] usb 4-1.1: New USB device
strings: Mfr=2, Product=3, SerialNumber=1
May 25 12:39:32 hier kernel: [79854.405900] usb 4-1.1: Product:
Expansion Desk
May 25 12:39:32 hier kernel: [79854.405904] usb 4-1.1: Manufacturer: Seagate
May 25 12:39:32 hier kernel: [79854.405908] usb 4-1.1: SerialNumber:
NA4JDN4N
May 25 12:39:32 hier kernel: [79854.406710] usb-storage 4-1.1:1.0: USB
Mass Storage device detected
May 25 12:39:32 hier kernel: [79854.407068] scsi9 : usb-storage 4-1.1:1.0
May 25 12:39:32 hier kernel: [79854.655950] Buffer I/O error on device
dm-0, logical block 464117312
May 25 12:39:32 hier kernel: [79854.655959] Buffer I/O error on device
dm-0, logical block 464117312
May 25 12:39:33 hier kernel: [79855.407979] scsi 9:0:0:0: Direct-Access
    Seagate  Expansion Desk   070B PQ: 0 ANSI: 6
May 25 12:39:33 hier kernel: [79855.408847] sd 9:0:0:0: Attached scsi
generic sg1 type 0
May 25 12:39:33 hier kernel: [79855.410055] sd 9:0:0:0: [sdc] 732566645
4096-byte logical blocks: (3.00 TB/2.72 TiB)
May 25 12:39:33 hier kernel: [79855.411191] sd 9:0:0:0: [sdc] Write
Protect is off
May 25 12:39:33 hier kernel: [79855.411202] sd 9:0:0:0: [sdc] Mode
Sense: 43 00 00 00
May 25 12:39:33 hier kernel: [79855.412402] sd 9:0:0:0: [sdc] Write
cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 25 12:39:33 hier kernel: [79855.413245] sd 9:0:0:0: [sdc] 732566645
4096-byte logical blocks: (3.00 TB/2.72 TiB)
May 25 12:39:37 hier kernel: [79858.940027]  sdc: sdc1 sdc2
May 25 12:39:37 hier kernel: [79858.942029] sd 9:0:0:0: [sdc] 732566645
4096-byte logical blocks: (3.00 TB/2.72 TiB)
May 25 12:39:37 hier kernel: [79858.944241] sd 9:0:0:0: [sdc] Attached
SCSI disk
May 25 12:39:51 hier kernel: [79872.773254] Buffer I/O error on device
dm-0, logical block 17
May 25 12:39:51 hier kernel: [79872.773259] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773295] Buffer I/O error on device
dm-0, logical block 68681744
May 25 12:39:51 hier kernel: [79872.773297] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773327] Buffer I/O error on device
dm-0, logical block 68681774
May 25 12:39:51 hier kernel: [79872.773328] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773359] Buffer I/O error on device
dm-0, logical block 68681983
May 25 12:39:51 hier kernel: [79872.773360] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773390] Buffer I/O error on device
dm-0, logical block 68690183
May 25 12:39:51 hier kernel: [79872.773391] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773421] Buffer I/O error on device
dm-0, logical block 71303343
May 25 12:39:51 hier kernel: [79872.773422] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773452] Buffer I/O error on device
dm-0, logical block 72876154
May 25 12:39:51 hier kernel: [79872.773453] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773483] Buffer I/O error on device
dm-0, logical block 77070492
May 25 12:39:51 hier kernel: [79872.773485] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773514] Buffer I/O error on device
dm-0, logical block 98566225
May 25 12:39:51 hier kernel: [79872.773515] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773558] Aborting journal on device
dm-0-8.
May 25 12:39:51 hier kernel: [79872.773588] Buffer I/O error on device
dm-0, logical block 231768064
May 25 12:39:51 hier kernel: [79872.773590] lost page write due to I/O
error on dm-0
May 25 12:39:51 hier kernel: [79872.773600] JBD2: Error -5 detected when
updating journal superblock for dm-0-8.
May 25 12:39:51 hier kernel: [79872.773817] EXT4-fs warning (device
dm-0): ext4_end_bio:317: I/O error -19 writing to inode 17173338 (offset
2490368 size 131072 starting block 148009568)
May 25 12:39:51 hier kernel: [79872.773821] Buffer I/O error on device
dm-0, logical block 148009568
May 25 12:39:51 hier kernel: [79872.773827] Buffer I/O error on device
dm-0, logical block 148009569
May 25 12:39:51 hier kernel: [79872.773829] Buffer I/O error on device
dm-0, logical block 148009570
May 25 12:39:51 hier kernel: [79872.773830] Buffer I/O error on device
dm-0, logical block 148009571
May 25 12:39:51 hier kernel: [79872.773832] Buffer I/O error on device
dm-0, logical block 148009572
May 25 12:39:51 hier kernel: [79872.773834] Buffer I/O error on device
dm-0, logical block 148009573
May 25 12:39:51 hier kernel: [79872.773836] Buffer I/O error on device
dm-0, logical block 148009574
May 25 12:39:51 hier kernel: [79872.773838] Buffer I/O error on device
dm-0, logical block 148009575
May 25 12:39:51 hier kernel: [79872.773840] Buffer I/O error on device
dm-0, logical block 148009576
May 25 12:39:51 hier kernel: [79872.773841] Buffer I/O error on device
dm-0, logical block 148009577
May 25 12:39:51 hier kernel: [79872.773898] EXT4-fs warning (device
dm-0): ext4_end_bio:317: I/O error -19 writing to inode 17173338 (offset
2490368 size 131072 starting block 148009598)
May 25 12:39:51 hier kernel: [79872.773948] EXT4-fs warning (device
dm-0): ext4_end_bio:317: I/O error -19 writing to inode 40770054 (offset
3145728 size 8192 starting block 147922176)
May 25 12:39:51 hier kernel: [79872.773975] EXT4-fs warning (device
dm-0): ext4_end_bio:317: I/O error -19 writing to inode 40770076 (offset
3887104 size 4096 starting block 5281717)
May 25 12:39:51 hier kernel: [79873.230984] EXT4-fs error (device dm-0):
ext4_put_super:790: Couldn't clean up the journal
May 25 12:39:51 hier kernel: [79873.230990] EXT4-fs (dm-0): Remounting
filesystem read-only
May 25 12:39:51 hier kernel: [79873.230992] EXT4-fs (dm-0): previous I/O
error to superblock detected
May 25 12:44:07 hier kernel: [80128.859704] EXT4-fs (dm-0): recovery
complete
May 25 12:44:07 hier kernel: [80128.878030] EXT4-fs (dm-0): mounted
filesystem with ordered data mode. Opts: (null)

Which layer is saying "Buffer I/O error on device dm-0, logical block 0"
? Is it the LUKS module?

After one more round of trying to do a backup and failing I decided to
fsck the partition (the partition was unlocked via LUKS then):

    # fsck.ext4 -c -c -k
/dev/mapper/luks-446c3a20-eb34-45f6-9ff9-d4a5b17fdedd

That gave me after a while of running without error reports a never
ending series of fsck wanting me to confirm its actions. Stuff like:

    die Block-Bitmap (24117248) von Gruppe 736 ist ung├╝ltig.
Zur├╝cksetzen<j>? ja

Since I mount that disk with `gnome-disk` I noticed there, that the lock
on the LUKS encrypted parition had in the meantime become *closed*
again, without me doing anything.

Nevertheless fsck was happily continuing with its disk check.

So I think there are a few parts broken in this chain of layers. The one
that I can put a finger on is that fsck should notice or should be
notified when the block device under it ceases to exist, as is the case
when the LUKS device becomes locked again.

I'm not sure why fsck doesn't notice. Doesn't it get the right
information from the LUKS block device?

The end result of this is, that my backups are lost. The disk can still
be read, but LUKS is no more able to decipher it.

I'm not sure how to go forward from here. I know that I had a series of
problems with external USB drives allready:

* I've had to have my USB port re-soldered (one year ago) because
contact with attached devices had become unreliable - they would
disapear and reappear in the kernel log. After having been resoldered,
the port was reliable.

* ca. 7 months ago I had to throw away an external USB drive because
again it would be disappearing in `gnome-disk` after a few minutes of
doings backups onto it (same setup as today)

The current drive and the current re-soldered port were working reliably
since then though.

So I'm not sure which parts of the chain are broken now. However I think
that:

1. the information of "the device is gone" or "has problems" should be
logged by every layer from the bottom up to the top

However I am only able to see the USB layer do that:

  "usb 4-1.1: USB disconnect, device number 7"

I can't see any log message from the usb-storage that would let me know
that the device has disappeared.

Neither can I see LUKS telling me that it is relocking the device (which
`gnome-disk` is telling me it did).

Nor can I see ext4 telling me that the block device under it is gone.

2. the information of "the device is gone" should be passed from the
first layer that has that problem up through all following layers.

Why doesn't this apparently happen?

What's the way forward to fix this?

*t

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Rogier Wolff | 4 Feb 13:57 2015
Picon

block group descriptors.


Hi 

A friend of mine managed to corrupt his block group descriptor
table. When starting e2fsck, it says that it is corrupt and will use
the backup. Great!

However, will e2fsck be able to fix this, or will I have to do this
manually? The FSCK is still running, expected to finish "pass 1" in
about four hours.

	Roger. 

--

-- 
** R.E.Wolff <at> BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
Jelle de Jong | 8 Oct 18:28 2014
Picon

CF Card wear optimalisation for ext4


Hello everyone,

I been using CF cards for almost more then 7 years now with ext
file-system without any major problems on ALIX boards.

Last year I took 30 other systems in production with ext4 and the CF
cards been dropping out pretty fast, it may have been a bad batch but
I do want to look at it. I don't think the devices writes a lot of IO
(is there a tool that can give me some useful numbers for say 24H or a
week? iotop, atop, sysstat doesn?t seem suited for long term IO write
monitoring, but maybe I am misusing them and can use some help here)

I mount root with the following options:

/dev/disk/by-uuid/09a04c01-64c6-4600-9e22-525667bda3e3 on / type ext4
(rw,noatime,user_xattr,barrier=1,data=ordered)

# dumpe2fs /dev/sda1
http://paste.debian.net/hidden/e3f81f11/

Are there kernel options to avoid synchronous disk writes? As
suggested here: http://www.pcengines.ch/cfwear.htm

Is there a list of other kernel options I can optimise to limit any cf
wear? The devices don't use

Kind regards

Jelle de Jong
Norbert Preining | 27 Sep 14:07 2014
Picon
Gravatar

problems with usb stick after suspend and wake up

Dear all,

(please Cc)

I am running latest kernel (3.17-rc6) and I see corruption of an usb3.0
device usb stick. Strange errors, impossibility to mount.

Repeated unplugging and replugging helps sometimes, in all cases
recovery is necessary.

Is this a know problem, a problem of my system
Debian/sid, uptodate, self-compiled kernel
of the suspend program (that initiates the suspend), 
the usb stick and file system, or the USB subsystem?

I happily provide loads of further details about hardware, logs, whatever,
but first I ask before sending tons of useless stuff!?

Any idea?

Thanks a lot

Norbert

------------------------------------------------------------------------
PREINING, Norbert                               http://www.preining.info
JAIST, Japan                                 TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13
------------------------------------------------------------------------
jd1008 | 20 Sep 03:56 2014
Picon

Possible bug in mkfs.ext3

I am reporting this on the advice of the Fedora Users Mailing List Member.

This the mailing list exchange outlining the problem with specifying -S 
to mkfs,
and it's subsequent consequences when fsck is run.

I am reporting this per suggestions made to me on the Fedora Users 
Mailing List.

The following is the mailing list exchange:

On 09/18/2014 07:01 PM, Robert Nichols wrote:
> On 09/18/2014 12:37 PM, jd1008 wrote:
>> Is there any other tool that can extract files from a partition that
>> seems to have corrupted superblocks?
>> I tried dumpe2fs, and fsck -b <blockNumber>
>> to no avail. Tried all available block numbers that are listed
>> when original mkfs was done, and it's output was saved.
>>
>> None of the blocks seem to work - all of them have invalid magic.
>
> Verify that the partition table still appears to be correct.  If it
> is pointing to the wrong starting location, none of the super blocks
> will appear in the expected places. You might see if /testdisk/can
> find any intact super blocks.
>
> Consider using a hex editor to look at some of the super blocks.
> They should contain the same data.  The data that actually appears
> there might give some clue as to what happened.
>
> As a last ditch recovery effort, run mke2fs/mke3fs with the "-S"
> option to initialize the super blocks and group descriptors only.
> Do this only with (or on) a backup copy of the partition, since
> it is potentially destructive.  Then see if /debugfs/can make
> sense of the filesystem, and if so, run /fsck/with the "-f"
> option to repair the metadata. 

On 09/19/2014 07:16 PM, Chris Murphy wrote:
> On Sep 19, 2014, at 11:49 AM, jd1008 <jd1008 <at> gmail.com> wrote:
>
>> On 09/19/2014 08:39 AM, Robert Nichols wrote:
>>> On 09/18/2014 10:57 PM, jd1008 wrote:
>>>> I ran mkfs.ext3 -S  /dev/sdc7
>>>> then ran fsck.ext3 -y /dev/sdc7
>>>> it blew away EVERYTHING :)
>>>>
>>>> Back to square one and re-dd original to test drive
>>>> and start over.
>>> Ouch!  That _used_ to work.  Trying it just now, "mke3fs -S" seems
>>> to clear a substantial portion of the inodes, which the manpage
>>> specifically says it should _not_ do, and then /fsck/ completes the
>>> destruction by moving all of the remaining inodes to lost+found.
>>>
>>> Sorry about that.
>>>
>> Can raise a bug against it?
> Chances are this is an upstream bug, or a misunderstanding. You should post your reproduce steps to the
ext4 list, what you expect to happen based on man page, and what actually happens.
> http://vger.kernel.org/vger-lists.html#linux-ext4
>
>
> Chris Murphy
Bill Cunningham | 25 Aug 21:19 2014
Picon

filesystem

    I hope this is the right list. I have created an ext2 filesystem and 
removed the dir_index feature. I don't know if this kind of experimentation 
is going to help me learn something about filesystems or not. Well what is 
dir_index? Then I ran e2fsck -f -v -pD and the /dev file. Now what did I 
remove? Htree. I guess it can always be put back and it's on an experimental 
filesystem.

    What features separate ext4 from ext3 ? I have noticed too that ext2 
fragments quite a bit.

Bill
Bill Cunningham | 17 Aug 21:52 2014
Picon

extended filesystems

    I would like to start experiemnting with the ext filesystems. I might
like one day to develop something. :) What files contain the ext4
filesystem. That's what I'm running right now. I like ext 2/3/4 all of them.

    My fedora partition is only 20 GB in size. I don't need huge filesystem
support which is a feature of ext4 I believe. Which feature can I remove to
remove this feature? I know it would be done with tune2fs -O ^ and then the
feature name.

    Why would I want to do this. to learn and I don't think I need it. Too
much overhead.

Bill
Roland Olbricht | 17 Aug 19:28 2014
Picon
Picon

What uses these 50 GB?

Hello everybody,

first of all thank you the development of Ext2/3/4. It works like a 
charm and makes it possible to base applications on it.

However, now I have the first time where I need more information to 
understand the behaviour of a ext4 installation on a 480 GB harddisk.
It holds a database with a size of 355 GB, as said by

"du -m":

...
355263  /opt/ssd

However, "df" says:

Filesystem      1K-blocks       Used Available Use% Mounted on
...
/dev/sdc        468346644  409888536  35015532  93% /opt/ssd

I do understand why there is a gap between "Used" plus "Available" and 
"1K-blocks", but I don't understand why "Used" is so much bigger (54 GB 
difference) than what "du -m" indicates.

I can rule out any issues with inodes; "df -i" indicates that less than 
one percent is used.

I tried to understand more details by using "debugfs". I thought I get a 
full list of used blocks with:

for i in *; do { echo "blocks $i" | sudo debugfs /dev/sdc | grep -vE 
"^debugfs" | awk '{ for (i=1; i < NF; ++i) print $i; }'; }; done

which delivered 90938943 lines (containing block numbers allocated by 
visible files). But

echo "testb 1 117330000" | sudo debugfs /dev/sdc | grep "marked in use"

has delivered 102595007 lines (containing block numbers marked as "used").

I tried to learn more about blocks marked as "marked in use" but not by 
a known file, and

echo "icheck 98304 98305" | sudo debugfs /dev/sdc

returned

debugfs:  icheck 98304 98305
Block   Inode number
98304   <block not found>
98305   <block not found>

Could somebody explain to be what the purpose of these 11,656,064 blocks 
is that don't belong to an inode but are still marked as used?

Do I have a chance other than reformatting the drive to get back this space?

Best regards,

Roland
Ivan Baldo | 7 Jun 01:57 2014
Picon
Picon
Gravatar

Recommended minimal amount of free space to keep?

     Hello.
     So, LVM is cool, having different partitions for different stuff is 
cool, and of course Ext4 is cool and *reliable*.
     So, we create some logical partitions and put ext4 on them, 
reserving LVM space for growing those partitions or even making new ones 
later.
     The thing is, I would like to keep every filesystem as small as it 
can be, but without degrading the performance too much.
     I guess that having a filesystem 99% full will create too much 
fragmentation and many other issues, but having them only 30% full seems 
like a waste.
     Currently I try to keep them at 70% full utilization but I have not 
based that on anything just guess.
     So, what % hysteresis do you recommend? For example, when they get 
70% full then grow them so that they get 50% full? Other values?
     Thanks for the hints!
     Good day everyone.

--

-- 
Ivan Baldo - ibaldo <at> adinet.com.uy - http://ibaldo.codigolibre.net/
 From Montevideo, Uruguay, at the south of South America.
Freelance programmer and GNU/Linux system administrator, hire me!
Alternatives: ibaldo <at> codigolibre.net - http://go.to/ibaldo

Gmane