Commit Graph

10 Commits

Author SHA1 Message Date
Mike Fleetwood 7e441c8d87 Update HACKING file with coding style hints and tips 2021-03-24 16:22:41 +00:00
Mike Fleetwood 4b8d4be789 Remove unallocated space comment from HACKING file (!50)
The HACKING file should be hints for making changes to the code base and
associated processes.  A overview of how GParted handled unallocated
space was not that.  Also now the size of a JFS is accurately calculated
using JFS as an example of a file system with intrinsic unallocated
space is no longer valid.  Therefore removed from the HACKING file.
Instead add the original commit message as an extended comment to method
calc_significant_unallocated_sectors().

Closes !50 - Calculate JFS size accurately
2019-11-14 17:12:06 +00:00
Mike Fleetwood 77978ee7c1 Add translatable files reminder to HACKING file 2016-12-02 10:06:09 -07:00
Mike Fleetwood 7ebedc4bb3 Don't show intrinsic unallocated space (#499202)
Most file systems report intrinsic unallocated space using the statvfs()
system call when mounted, but not using their own tools.  They are:
ext2/3/4, fat16/32, hfs, nilfs2, reiserfs and xfs.  Showing either a
little or no unallocated space, depending on whether a file system is
mounted or not, could be confusing to the user.

When all file systems are created filling their partitions the unused
figure reported by statvfs() and their own tools are the same or very
close.  Also the used plus unallocated figure from statvfs() agrees with
the used figure from their own tools.

For all file systems don't display intrinsic unallocated space (that
below the threshold of 2 to 5%), instead include it as used space.  As
soon as the amount of unallocated space becomes significant display it
everywhere and also trigger the warning.

For display purposes always use the new Partition methods:
get_sectors_used(), get_sectors_unused(), and get_sectors_unallocated().
When calculating new usage figures during Paste and Resize/Move
operations directly access sectors_used, sectors_unused and
sectors_unallocated members.

Bug #499202 - gparted does not see the difference if partition size
              differs from filesystem size
2012-06-18 12:41:59 -06:00
Mike Fleetwood b5c80f18a9 Enhance calculation of significant unallocated space (#499202)
Many file systems report differing percentages of unallocated space over
a range of sizes, as well differing figures using their own specific
tools or using statvfs() system call when mounted.

File systems reporting intrinsic unallocated space using their specific
tools are: jfs, lvm2 pv and ntfs.  LVM2 PV has the largest amount of
unallocated space with its default Physical Extent size of 4 MiB.  For a
100 MiB partition it has 4.0% unallocated space.

File systems reporting intrinsic unallocated space using the statvfs()
system call when mounted are: ext2/3/4, fat16/32, hfs, jfs, nilfs2,
ntfs, reiserfs, and xfs.  Xfs has the worst identified unallocated space
of ~4.7% in a 100 MiB partition.  Ext2/3 exhibit unusual behaviour by
reporting unallocated space of ~4.6% in a 100 MiB partition falling to a
constant percentage of ~1.8% for sizes of 1 GiB and above.

Update the calculation for used to estimate the maximum size of
intrinsic unallocated space.  Limit is now 5% for partitions smaller
than 100 MiB, 2% for partitions larger than 1 GiB and linear scaling of
the percentage between.  Will still get false unallocated space warnings
for mounted xfs file systems and lvm2 pvs smaller than 100 MiB.

Also add a short note and worked example calculation of unallocated
space to the HACKING file.

Bug #499202 - gparted does not see the difference if partition size
              differs from filesystem size
2012-06-18 10:24:29 -06:00
Curtis Gedak 3fdf17b68e Update HACKING notes with git specific comments 2009-04-19 15:44:31 -06:00
Curtis Gedak 93e52e1118 Changed text CVS to SVN.
svn path=/trunk/; revision=927
2008-10-08 21:23:54 +00:00
Curtis Gedak 52acaf23e4 Changed text CVS to SVN.
svn path=/trunk/; revision=926
2008-10-08 21:19:01 +00:00
Bart Hakvoort b17908e317 update 2004-09-30 21:01:19 +00:00
Bart Hakvoort 6d9be33e0d thanks to Paolo ;) 2004-09-23 08:33:59 +00:00