On 20:34 Thu 14 Feb , emmanuel segura wrote: > man tune2fs > > -r reserved-blocks-count > Set the number of reserved filesystem blocks. > > be careful with filesystem reserved block, one time i had a production > server with / corrupted >
I have a very specific use here. I am using this partition only for 1 time backup of static data, on a backup machine. I am confused. I had set the reseved block count to 0 with the tune2fs -m0 option. This is because I dont use this device for system or root. Just data storage. However I see on the system currently (after only doing tune2fs -m0) 1. File system features of resize_inode 2. Reserved block count 0 3. Reserved GDT blocks 1002 what is the idea here of tune2fs -r? It says currently that reserved block count is 0. Should I want to get rid f the GDT blocks? Are they the only culprit remaining? Are they only used for resizing? I will not need to resize once I do my full data backup to this partition. I am confused because I don't understand the -r option vs the -m 0 option. According to the following comment from Theodore Tso author of ext2/3/4 http://www.redhat.com/archives/ext3-users/2006-May/msg00008.html " > 1) what does the "Reserved GDT blocks" mean? and what > are its functions and purposes? It means that blocks have been reserved in order to allow on-line resizing. The filesystem will also have "resize_inode" in the filesystem features line reported by dumpe2fs. This is most useful if the filesystem has been created on a Logical Volume managed by an LVM system so that when the LV is expanded, the filesystem can take advantage of the new disk space without needing to unmount the filesystem first. Filesystems that don't have this set can of course still be resized off-line using resize2fs. " I want to understand. Does the -r option turn off the reside_inode reserved space?? what number to put after -r? Is that what I want to do? Are there any good online references to the next step to get back space, if it is safe to do? Thanks Mitchell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130214203617.gb19...@earthlink.net
