Bug#737247: gparted resizes partition to smaller than the filesystem
On 2/5/2014 12:47 PM, Curtis Gedak wrote: Further, by undoing the following commit, the resize/move operation proceeded past the failed e2fschk operation. :-) Shrink file systems to exact size (#701075) https://git.gnome.org/browse/gparted/commit/?id=3461413d283f1bac77e541b1054e775ec105212f I believe that -1 was masking the real error, which is in the partition resize code, since the new size of the partition is not an even multiple of 4k. The end sector also is not aligned to a 1 MiB boundary. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
On 14-02-05 11:14 AM, Phillip Susi wrote: I believe that -1 was masking the real error, which is in the partition resize code, since the new size of the partition is not an even multiple of 4k. The end sector also is not aligned to a 1 MiB boundary. Good catch Phillip. This operation is a shrink and move, and the temporary location of the shrunken file system is not the final destination. Having said that I think there might be a problem with the final location not being MiB aligned. With the commit reverted, the next step in the gparted_details.htm log file is to grow the partition to an all-encompassing partition and this end sector value is _not_ MiB aligned. Log file snippet follows.: grow partition from 342.80 GiB to 1.82 TiB 00:00:01( SUCCESS ) old start: 2048 old end: old size: 718893231 (342.80 GiB) new start: 2048 new end: 3907029166 new size 3907027119 (1.82 TiB) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Hi Anomie, Thank you for your further investigation and for posting the steps you used. By using the steps Mike first published and you outlined in detail, I was able to recreate the problem you experienced. Further, by undoing the following commit, the resize/move operation proceeded past the failed e2fschk operation. :-) Shrink file systems to exact size (#701075) https://git.gnome.org/browse/gparted/commit/?id=3461413d283f1bac77e541b1054e775ec105212f However, rather than simply reverting the commit, I think the original logic assumed a 512 byte sector size and was trying to ensure that the resize command in kiB did not exceed the partition size in sectors. I will investigate a solution that uses something like floor() instead of round() to ensure that the resize command in kiB is always the same or smaller than the partition size in sectors. Regards, Curtis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/5/2014 1:14 PM, Phillip Susi wrote: I believe that -1 was masking the real error, which is in the partition resize code, since the new size of the partition is not an even multiple of 4k. The end sector also is not aligned to a 1 MiB boundary. As far as the rounding goes, that appears to be the cause of the problem: the size in sectors should NOT be rounded up. Remove the call to Utils::round() and it should get rid of the fsck error, though I still wonder why the partition is being given the wrong size in the first place. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS8oJoAAoJEI5FoCIzSKrwb0kIAIDE3Duzlgx2mjPpwM0xL6DD On/5SpVxXwtOcVa8xk56769RLJpH+zv0hloCuH1kEaAAVRxtX9j3udsAeuZH/Gh1 TSnIvIX0rK7XSEGLA36DiCImxznPJvi9pB2PL7FJri54Ayo0lODbK/pF2rjicnhw H2HW49KdP9TfQZ52fVi9eKRgGrAoerwy9ODky6N9TN+RLB44EqlSg+TcLec+lv80 xixuWrCFeE6Ty0UyQkBQkBAc89bfyeHNRzbf6VTqXOKqbrA4V2IJoe8iFsBvEmC+ 1rQtNlMMeZPEA7y1n9Wq7nfNCqHjyMi2JEESvbvU2qaFOdABfmFViRkCW97O4Lg= =OGlK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
On 14-02-05 11:28 AM, Curtis Gedak wrote: On 14-02-05 11:14 AM, Phillip Susi wrote: I believe that -1 was masking the real error, which is in the partition resize code, since the new size of the partition is not an even multiple of 4k. The end sector also is not aligned to a 1 MiB boundary. From thinking further on this, the question of MiB alignment likely belongs in a different bug report, since this changes the behavior of how GParted has been working in the past. In this bug report, the partition has been shrunk and moved to the right by the user changing the starting sector. The end sector is never changed throughout the operation (by the user or GParted). I'm not saying that this is right or wrong, but I think it should be dealt with separately. The primary focus is to at least get back to the original behaviour of GParted in which the operation successfully completes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
On Wed, Feb 05, 2014 at 01:14:23PM -0500, Phillip Susi wrote: The end sector also is not aligned to a 1 MiB boundary. The explanation for that seems simple enough: this drive itself is not a multiple of 1 MiB in size, the partition was using the whole drive, and I never told gparted to change the end position of the partition. If gparted had insisted on ignoring the last 89600 bytes of the drive, I'd probably have changed to None alignment (if I noticed). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well that explains the alignment issue and is probably fine then. I am attaching a patch to the upstream bug report to fix the incorrect rounding. If it looks good to you Curtis, I'll apply it to the debian package and get it uploaded tonight and synced to Ubuntu tomorrow in time for the trusty debian import freeze. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS8oiBAAoJEI5FoCIzSKrwVB8IAI4nnQd3MxQokRTOW7Y3TAuk t6+Y2MMwFbVCc15zgKKWXGNaryb2eJHNENksU0BudznHIKlXl9rnHatJ0cufJOGg xiL9xp4f5wtfFgSVp2beB4zPAgBW1pOFADZlRWUSkDtkJ46kLSqSknzG4FnEKJf5 ovSoiYZ6h5zqbPKyIgu2oRend6aA00Usj7t9I6GVmqsP60gv/easRkKfbL66ssRx 6oLnfdorBzYB9jk68tpOIB8BidE5ir5t36BFViEkIs1k+Y3rUKWZxDcIXWY7VX7B dmU6cqtUl7Xa8DQg3HGVBd7r1+pjODpa9gITgNBquKmjptBjQJ7geB+3VuMQIIk= =0fAM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Because this problem would affect all GNU/Linux distributions running GParted, I have created an upstream bug. The relevant upstream bug report is: Bug 723543 - Shrink ext2/3/4 results in attempt to set partition smaller than file system https://bugzilla.gnome.org/show_bug.cgi?id=723543 Please place future discussion of the problem in this upstream bug report. Thanks, Curtis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Hi Anomie, Can you confirm the version of Debian you are using as my attempt to re-create the bug on my normal distribution didn't find an issue. https://bugzilla.gnome.org/show_bug.cgi?id=723543#c2 Thanks, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Hi Anomie, I too have been unable to recreate the problem you experienced. In addition to Mike's question would you be able to provide answers to the following? Which alignment option did you choose? (MiB, Cylinder, or None. Default is MiB) Would you be able to provide the output from the following two commands? sudo fdisk -l -u where one of the options is a lower case L and not the number one. sudo parted /path-to-your-device unit s print where /path-to-your-device is something like /dev/sda Thanks, Curtis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
On Mon, Feb 03, 2014 at 07:45:39PM +, Mike Fleetwood wrote: Can you confirm the version of Debian you are using as my attempt to re-create the bug on my normal distribution didn't find an issue. I'm using unstable. gparted version 0.17.0-4. On Mon, Feb 03, 2014 at 02:02:34PM -0700, Curtis Gedak wrote: Which alignment option did you choose? (MiB, Cylinder, or None. Default is MiB) I left it at the default. Would you be able to provide the output from the following two commands? sudo fdisk -l -u Note I've finished repartitioning the drive since this bug report.[1] Disk /dev/sdc: 2000.4 GB, 2000398933504 bytes 81 heads, 62 sectors/track, 777982 cylinders, total 3907029167 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00023c76 Device Boot Start End Blocks Id System /dev/sdc12048 3907029166 1953513559+ 83 Linux sudo parted /path-to-your-device unit s print Model: Seagate GoFlex Desk (scsi) Disk /dev/sdc: 3907029167s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 2048s 3907029166s 3907027119s primary On Mon, Feb 03, 2014 at 07:45:39PM +, Mike Fleetwood wrote: https://bugzilla.gnome.org/show_bug.cgi?id=723543#c2 Based on that, I managed to recreate the issue as follows: $ truncate -s 2000398933504 /tmp/loop0.img $ sudo losetup -f --show /tmp/loop0.img /dev/loop0 $ echo -e o\nn\np\n\n\n\nw\nq\n | sudo fdisk /dev/loop0 [...] $ sudo partprobe -s /dev/loop0 /dev/loop0: msdos partitions 1 $ sudo fdisk -l /dev/loop0 Disk /dev/loop0: 2000.4 GB, 2000398933504 bytes 81 heads, 62 sectors/track, 777982 cylinders, total 3907029167 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xcf75b6a0 Device Boot Start End Blocks Id System /dev/loop0p12048 3907029166 1953513559+ 83 Linux $ sudo mkfs.ext4 -q /dev/loop0p1 $ sudo gparted /dev/loop0 * Select the partition * Click Resize/Move * Drag the left end of the slider to the right. This time it says free space preceeding is 1556706, size is 351022, free space following is 0, align is MiB. * Hit Ok and confirm. Then apply. * The output is roughly the same as in the original attachment: the resize2fs step reports the new filesystem is 89861654 blocks, the partition shrink takes it down to 718893231 sectors, then the e2fsck complains that the filesystem is 89861654 blocks while the device is only 89861653. Then I removed the loop device, deleted /tmp/loop0.img, and redid the above except I typed 160 in the free space before box instead of using the slider. e2fsck again failed saying the filesystem was 78778390 blocks while the partition was 78778389. And I did it again a few more times, same sort of results each time. [1]: The plan was to shrink the existing filesystem, move it to the end of the disk, create a new dm-crypt partition taking up most of the disk, copy everything from the old to the new, delete the old, expand the new to use the whole disk again, and then at some point run zerofree or the like over it. gparted was supposed to make it so I didn't have to worry about matching filesystem blocks and disk sectors when shrinking and moving... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Hi Anomie and Phillip, There was a recent change in GParted 0.16.2 that is directly related to resizing ext2/3/4 file systems. Specifically the change no longer subtracts 1 kiB from the file system size which would have prevented this problem from occurring. The relevant commit is: Shrink file systems to exact size (#701075) https://git.gnome.org/browse/gparted/commit/?id=3461413d283f1bac77e541b1054e775ec105212f In my resize testing of ext2/3/4 I have not encountered this problem, but based on the bug report gparted_details.htm log file there exists at least one situation where the file system is resized at least 1 sector bigger than the partition. I CC'd Mike Fleetwood on this so that he is aware of this problem. Any thoughts Mike? Curtis On 14-01-31 06:51 PM, Phillip Susi wrote: Yikes, looks like gparted has an off by one: it set the partition size one sector two small. Do you have any thoughts on this Curtis? On 01/31/2014 02:16 PM, ano...@users.sourceforge.net wrote: Package: gparted Version: 0.17.0-4 I tried to shrink-and-move a partition on an external hard drive. It seems that gparted shrunk the parition to 93768726 4K blocks, but then resized the parition to only 750149807 512-byte sectors (93768725.875 4K blocks). The post-shrink e2fsck then errored out before the partition could be moved. gparted log attached. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/02/2014 12:35 PM, Curtis Gedak wrote: Hi Anomie and Phillip, There was a recent change in GParted 0.16.2 that is directly related to resizing ext2/3/4 file systems. Specifically the change no longer subtracts 1 kiB from the file system size which would have prevented this problem from occurring. The relevant commit is: Shrink file systems to exact size (#701075) https://git.gnome.org/browse/gparted/commit/?id=3461413d283f1bac77e541b1054e775ec105212f That's resizing the filesystem. This case appears to be the partition getting set to the wrong size. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS7pkJAAoJEI5FoCIzSKrwH08IAJE582oxcDvLgR/HxVk4PB17 0LhBUhM390MG48a783fB/dnvrksE+Z6CMvAF2bVF7zoyNSdZeJbl1RV882x+5n9a 2pENogkHGU8wScDP/qplQXs1NhQ+dXC91vA3BfvBvSq4Aane97DEKzAphKL3fxgM d6bViUnLZJkKQ35J2+Q9psI6G00TBbwvW67RhIDW/v/YMm3eWY0M2aDluI7JHWW8 n5r7Za4HPcIoICffh8cei4qpIDelT2QDfiGotjZfsRYn4yUBpMPUQPECZxJCXpoS oLKl6Z6jLRJKNdYnxb9P63v6Cv2n0QTM9oke7M+xOZ53Qku9muOvr3euUs7yB64= =Cr0h -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Hi Phillip, With this problem recently cropping up, I do think that restoring the code back to the way it was will fix this problem. The reason is that the file system will be resized slightly smaller. Then it will fit within the same partition size. In other words it is a different way of tackling the problem. Instead of making the partition bigger, we instead make the file system smaller. There are some rounding operations in the code to ensure that ext2/3/4 resizing will match to an integer value of kiB. By removing the part where 1 kiB is subtracted before the rounding operation, we have inadvertently permitted the file system to be rounded up to 1 kiB more than it would have been with the old code. We might have to think about other sector sizes too now that 4k sector drives are becoming more widely available. At least those are my thoughts at the moment. I would like to hear from Mike too because he was involved in this recent change and might be able to shed more light on the subject. Curtis On 14-02-02 12:14 PM, Phillip Susi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/02/2014 12:35 PM, Curtis Gedak wrote: Hi Anomie and Phillip, There was a recent change in GParted 0.16.2 that is directly related to resizing ext2/3/4 file systems. Specifically the change no longer subtracts 1 kiB from the file system size which would have prevented this problem from occurring. The relevant commit is: Shrink file systems to exact size (#701075) https://git.gnome.org/browse/gparted/commit/?id=3461413d283f1bac77e541b1054e775ec105212f That's resizing the filesystem. This case appears to be the partition getting set to the wrong size. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Initial reaction is that these days it is unusual to have an odd number of sectors in a partition. I guess cylinder or no alignment was used, rather than the default MiB alignment. I'll have a closer look over the next day or so and see if I can work out what's going wrong. Mike (For my reference this is Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737247) On 2 February 2014 19:44, Curtis Gedak ged...@gmail.com wrote: ... I would like to hear from Mike too because he was involved in this recent change and might be able to shed more light on the subject. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/02/2014 04:24 PM, Mike Fleetwood wrote: Initial reaction is that these days it is unusual to have an odd number of sectors in a partition. I guess cylinder or no alignment was used, rather than the default MiB alignment. Yes, the partition should be an even multiple of 4K and is instead, one sector short, so the problem doesn't seem to be with resizing the filesystem. I didn't think gparted *had* any other options for alignment other than MiB? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS7vuoAAoJEI5FoCIzSKrwQPQIAKJSd/gIySDFBiFQc13ON3o9 tEjlfg4e+FLpxvhX7EVt4nHifGUiY5Buky/kmVikSVRqZen+ueppJyg70dQ/OqRU v6BRAvy5AlL51K5SnL5hzYYR01JBnIypqfESVavPWK9NuwwFZ5MIQQmlwo2GQnaO 60DC/m5SGzMwY19rNG4Fq6vRZlkgoOb+tBXJhV5Dlzwo2N8gtLvMowIDVWs2TvtF s783n+X/8RbaGNHRny1Da9u7V9DmBJCQmZIiKpp9YGvEGhpZ4M2tPfPNqi3Z2et5 tdcrgDYfCQgsBIRyOPqIolfJJj/KLMeHjaExoiGrO1m0nce4xF5A+BEg1Olv/Oo= =5RaA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737247: gparted resizes partition to smaller than the filesystem
Package: gparted Version: 0.17.0-4 I tried to shrink-and-move a partition on an external hard drive. It seems that gparted shrunk the parition to 93768726 4K blocks, but then resized the parition to only 750149807 512-byte sectors (93768725.875 4K blocks). The post-shrink e2fsck then errored out before the partition could be moved. gparted log attached. Title: GParted Details GParted 0.17.0 --enable-libparted-dmraid --enable-online-resize Libparted 2.3 Move /dev/sdb1 to the right and shrink it from 1.82 TiB to 357.70 GiB00:34:04( ERROR ) calibrate /dev/sdb100:00:00( SUCCESS ) path: /dev/sdb1start: 2048end: 3907029166size: 3907027119 (1.82 TiB) check file system on /dev/sdb1 for errors and (if possible) fix them00:12:59( SUCCESS ) e2fsck -f -y -v -C 0 /dev/sdb1 Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structure Pass 3: Checking directory connectivityPass 4: Checking reference counts Pass 5: Checking group summary information 720259 inodes used (0.59%, out of 122101760)1666 non-contiguous files (0.2%) 256 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 54238/1153/481366570 blocks used (16.66%, out of 488378389) 0 bad blocks 51 large files 576227 regular files 134638 directories1120 character device files 740 block device files 24 fifos 0 links7472 symbolic links (6954 fast symbolic links) 29 sockets 720250 files e2fsck 1.42.9 (28-Dec-2013) shrink file system00:21:05( SUCCESS ) resize2fs -p /dev/sdb1 375074904K Resizing the filesystem on /dev/sdb1 to 93768726 (4k) blocks.Begin pass 2 (max = 2011620)Relocating blocks Begin pass 3 (max = 14905)Scanning inode table Begin pass 4 (max = 135768)Updating inode references The filesystem on /dev/sdb1 is now 93768726 blocks long. resize2fs 1.42.9 (28-Dec-2013) shrink partition from 1.82 TiB to 357.70 GiB00:00:00( SUCCESS ) old start: 2048old end: 3907029166old size: 3907027119 (1.82 TiB) new start: 2048new end: 750151854new size: 750149807 (357.70 GiB) check file system on /dev/sdb1 for errors and (if possible) fix them00:00:00( ERROR ) e2fsck -f -y -v -C 0 /dev/sdb1 The filesystem size (according to the superblock) is 93768726 blocksThe physical size of the device is 93768725 blocksEither the superblock or the partition table is likely to be corrupt!Abort? yes e2fsck 1.42.9 (28-Dec-2013)
Bug#737247: gparted resizes partition to smaller than the filesystem
Yikes, looks like gparted has an off by one: it set the partition size one sector two small. Do you have any thoughts on this Curtis? On 01/31/2014 02:16 PM, ano...@users.sourceforge.net wrote: Package: gparted Version: 0.17.0-4 I tried to shrink-and-move a partition on an external hard drive. It seems that gparted shrunk the parition to 93768726 4K blocks, but then resized the parition to only 750149807 512-byte sectors (93768725.875 4K blocks). The post-shrink e2fsck then errored out before the partition could be moved. gparted log attached. Title: GParted Details GParted 0.17.0 --enable-libparted-dmraid --enable-online-resize Libparted 2.3 Move /dev/sdb1 to the right and shrink it from 1.82 TiB to 357.70 GiB00:34:04( ERROR ) calibrate /dev/sdb100:00:00( SUCCESS ) path: /dev/sdb1start: 2048end: 3907029166size: 3907027119 (1.82 TiB) check file system on /dev/sdb1 for errors and (if possible) fix them00:12:59( SUCCESS ) e2fsck -f -y -v -C 0 /dev/sdb1 Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structure Pass 3: Checking directory connectivityPass 4: Checking reference counts Pass 5: Checking group summary information 720259 inodes used (0.59%, out of 122101760)1666 non-contiguous files (0.2%) 256 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 54238/1153/481366570 blocks used (16.66%, out of 488378389) 0 bad blocks 51 large files 576227 regular files 134638 directories1120 character device files 740 block device files 24 fifos 0 links7472 symbolic links (6954 fast symbolic links) 29 sockets 720250 files e2fsck 1.42.9 (28-Dec-2013) shrink file system00:21:05( SUCCESS ) resize2fs -p /dev/sdb1 375074904K Resizing the filesystem on /dev/sdb1 to 93768726 (4k) blocks.Begin pass 2 (max = 2011620)Relocating blocks Begin pass 3 (max = 14905)Scanning inode table Begin pass 4 (max = 135768)Updating inode references The filesystem on /dev/sdb1 is now 93768726 blocks long. resize2fs 1.42.9 (28-Dec-2013) shrink partition from 1.82 TiB to 357.70 GiB00:00:00( SUCCESS ) old start: 2048old end: 3907029166old size: 3907027119 (1.82 TiB) new start: 2048new end: 750151854new size: 750149807 (357.70 GiB) check file system on /dev/sdb1 for errors and (if possible) fix them00:00:00( ERROR ) e2fsck -f -y -v -C 0 /dev/sdb1 The filesystem size (according to the superblock) is 93768726 blocksThe physical size of the device is 93768725 blocksEither the superblock or the partition table is likely to be corrupt!Abort? yes e2fsck 1.42.9 (28-Dec-2013) signature.asc Description: OpenPGP digital signature
