Cannot reduce filesystem size
Cannot reduce fs size
I have little issue reducing the fs on AIX .5.3. Here is what I get
root@dccccc-svc/etc>df -g /data/edw/init_stg
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/init_stg_lv01 793.00 425.25 47% 1081 1%
/data/edw/init_stg
root@dccccc-svc/etc>oslevel -s
5300-08-03-0831
root@dccccc-svc/etc>
root@dccccc-svc/etc>chfs -a size=-10G /data/edw/init_stg
chfs: There is not enough free space to shrink the file system.
System Model: IBM,9131-52A
Machine Serial Number: 0xxxxxxxxxx
Processor Type: PowerPC_POWER5
Processor Implementation Mode: POWER 5
Processor Version: PV_5_3
Number Of Processors: 4
Processor Clock Speed: 1648 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
LPAR Info: 3 dccccc-normal
Memory Size: 32000 MB
Good Memory Size: 32000 MB
Platform Firmware level: SF240_332
Firmware Version: IBM,SF240_332
That happens when you try to reduce a big chunk of data (in this case
10G) that may not be contiguous in the filesystem because you have files
scattered everywhere.
1. Try to defrag the FS
#defragfs -s /data/edw/init_stg
2. If you still can't reduce it after this. Try reducing the FS in
smaller chunks.
Instead of 10G at a time, try reducing 1 or 2 gigs. Then, repeat the
operation.
3. Try looking for files large using the find cmd and move them out
temporarily, just to see if we can shrink the fs without them:
#find /<filesystem> -xdev -size +2048 -ls|sort -r +6|pg
4. Sometimes processes open big files and use lots of temporary space in
those filesystem.
You could check processes/applications running against the filesystem
and stop them temporarily, if you can.
#fuser -cu[x] <filsystem>
Please, let me know if this works.
------------------------------------------
Explanations to the behavior of shrinkfs:
In the beginning of the JFS2 filesystem, there is the superblock, the
superblock backup, and then the data and metadata of the filesystem. At
the end is the inline log (if there is one), and the fsck working area.
The way the filesystem shrink works is this: When chfs is run and a
size is given (either -NUM or an absolute NUM size) AIX calculates where
that exists within the filesystem. This marker is known as "the fence".
The system then calculates how much data is left outside the fence, that
must be moved inside it (since we don't want to lose data). It
calculates the free space available, and subtracts a minimal amount for
the fsck working area and inline log (if any) that must go at the tail
end of the filesystem.
What chfs has to do is some complex calculating: in the area outside the
fence, is there any data to be saved and moved inside? In the area
inside the fence, how much data is there? Is it contiguous? How much
free space is there we have to play with? Is there enough space to move
the data from outside the fence inside it to save it? And lastly, is
there enough space to move the fsck working area and inline logs inside
also along with these?
It does not try to reorganize the data in any way. If a large file
outside the fence is make up of contiguous extents, then AIX looks for
an equivalent contiguous free space area inside the fence to move the
file to. If it can't find one, either due to a lack of space or free
space fragmentation, it fails this operation and won't shrink the
filesystem. The chfs shrink will also not purposely fragment a file to
force it to fit within fragmented free space.
In some cases running defragfs on the filesystem to defragment the files
will help, but many times it doesn't. The reason is because the purpose
of defragfs is to coalesce files into more contiguous extents, but not
to coalesce the free space in between them.
If non-contiguous free space is the issue, the only way to get them to
coalesce into large enough regions is to back up the data, remove it,
and restore it. Then the filesystem shrink may find enough contiguous
free space when chfs is run to move the data outside the fence into.
There's a limit to how much chfs can shrink a filesystem. This is
because chfs has to take into account not only the data you are
moving around, but it tries to keep the contiguous blocks of data in
files still contiguous. So if you have a filesystem with a lot of
space that is broken up into small areas, but you are moving around
large files it may fail even though it looks like you have a lot of
space left to shrink.
The free space reported by the df command is not necessary the space
that can be truncated by a shrinkFS request due to filesystem
fragmentation. A fragmented filesystem may not be shrunk if it does
not have enough free space for an object to be moved out of the region
to be truncated, and shrinkFS does not perform filesystem
defragmentation. In this case, the chfs command should fail with the
returned message: chfs: There is not enough free space to shrink the
file system - return code 28 (ENOSPC).
One of the common areas we see that limits customers is the
inclusion of large, unfragmented files in a filesystem, such as binary
database files. If a filesystem consists of a few, but extremely large
files, depending on how these are laid out the chfs may fail to find
enough space to move the data from outside the fence into it if it were
to attempt to shrink the filesystem.
Cannot reduce fs size
I have little issue reducing the fs on AIX .5.3. Here is what I get
root@dccccc-svc/etc>df -g /data/edw/init_stg
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/init_stg_lv01 793.00 425.25 47% 1081 1%
/data/edw/init_stg
root@dccccc-svc/etc>oslevel -s
5300-08-03-0831
root@dccccc-svc/etc>
root@dccccc-svc/etc>chfs -a size=-10G /data/edw/init_stg
chfs: There is not enough free space to shrink the file system.
System Model: IBM,9131-52A
Machine Serial Number: 0xxxxxxxxxx
Processor Type: PowerPC_POWER5
Processor Implementation Mode: POWER 5
Processor Version: PV_5_3
Number Of Processors: 4
Processor Clock Speed: 1648 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
LPAR Info: 3 dccccc-normal
Memory Size: 32000 MB
Good Memory Size: 32000 MB
Platform Firmware level: SF240_332
Firmware Version: IBM,SF240_332
That happens when you try to reduce a big chunk of data (in this case
10G) that may not be contiguous in the filesystem because you have files
scattered everywhere.
1. Try to defrag the FS
#defragfs -s /data/edw/init_stg
2. If you still can't reduce it after this. Try reducing the FS in
smaller chunks.
Instead of 10G at a time, try reducing 1 or 2 gigs. Then, repeat the
operation.
3. Try looking for files large using the find cmd and move them out
temporarily, just to see if we can shrink the fs without them:
#find /<filesystem> -xdev -size +2048 -ls|sort -r +6|pg
4. Sometimes processes open big files and use lots of temporary space in
those filesystem.
You could check processes/applications running against the filesystem
and stop them temporarily, if you can.
#fuser -cu[x] <filsystem>
Please, let me know if this works.
------------------------------------------
Explanations to the behavior of shrinkfs:
In the beginning of the JFS2 filesystem, there is the superblock, the
superblock backup, and then the data and metadata of the filesystem. At
the end is the inline log (if there is one), and the fsck working area.
The way the filesystem shrink works is this: When chfs is run and a
size is given (either -NUM or an absolute NUM size) AIX calculates where
that exists within the filesystem. This marker is known as "the fence".
The system then calculates how much data is left outside the fence, that
must be moved inside it (since we don't want to lose data). It
calculates the free space available, and subtracts a minimal amount for
the fsck working area and inline log (if any) that must go at the tail
end of the filesystem.
What chfs has to do is some complex calculating: in the area outside the
fence, is there any data to be saved and moved inside? In the area
inside the fence, how much data is there? Is it contiguous? How much
free space is there we have to play with? Is there enough space to move
the data from outside the fence inside it to save it? And lastly, is
there enough space to move the fsck working area and inline logs inside
also along with these?
It does not try to reorganize the data in any way. If a large file
outside the fence is make up of contiguous extents, then AIX looks for
an equivalent contiguous free space area inside the fence to move the
file to. If it can't find one, either due to a lack of space or free
space fragmentation, it fails this operation and won't shrink the
filesystem. The chfs shrink will also not purposely fragment a file to
force it to fit within fragmented free space.
In some cases running defragfs on the filesystem to defragment the files
will help, but many times it doesn't. The reason is because the purpose
of defragfs is to coalesce files into more contiguous extents, but not
to coalesce the free space in between them.
If non-contiguous free space is the issue, the only way to get them to
coalesce into large enough regions is to back up the data, remove it,
and restore it. Then the filesystem shrink may find enough contiguous
free space when chfs is run to move the data outside the fence into.
There's a limit to how much chfs can shrink a filesystem. This is
because chfs has to take into account not only the data you are
moving around, but it tries to keep the contiguous blocks of data in
files still contiguous. So if you have a filesystem with a lot of
space that is broken up into small areas, but you are moving around
large files it may fail even though it looks like you have a lot of
space left to shrink.
The free space reported by the df command is not necessary the space
that can be truncated by a shrinkFS request due to filesystem
fragmentation. A fragmented filesystem may not be shrunk if it does
not have enough free space for an object to be moved out of the region
to be truncated, and shrinkFS does not perform filesystem
defragmentation. In this case, the chfs command should fail with the
returned message: chfs: There is not enough free space to shrink the
file system - return code 28 (ENOSPC).
One of the common areas we see that limits customers is the
inclusion of large, unfragmented files in a filesystem, such as binary
database files. If a filesystem consists of a few, but extremely large
files, depending on how these are laid out the chfs may fail to find
enough space to move the data from outside the fence into it if it were
to attempt to shrink the filesystem.
