| Summary: | gentoo-sources-2.6.39-r3 - XFS filesystem wedges during heavy metadata update | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Lyall Pearce <Lyall> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
Filesystems layout - showing raid and lvm config raid configuration /etc/mdadm.conf |
||
Created attachment 282285 [details]
Filesystems layout - showing raid and lvm config
Added filesystem layout.
Created attachment 282287 [details]
raid configuration /etc/mdadm.conf
Added raid configuration.
I have done the build on a different computer which uses a very similar filesystem structure using LVM, and it worked. However, the computer that worked did not have raid1 but does have partition encryption. The computer that fails still has the build pending, so if there are any instructions I should follow before, during or after the update, please let me know. Work around found.
Increase log size of xfs filesystem and changing a mount optoin, allowed build to complete successfully.
It appears a large 'transaction' fills the transaction log and if the log is full, nothing happens, from then on.
I suggest that the bug remain open as something should fail, rather than hang.
I changed the XFS parameters FROM
root@lyalls-pc ~
# xfs_info /tmp
meta-data=/dev/mapper/vg-tmp isize=256 agcount=4, agsize=1310720 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=5242880, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
root@lyalls-pc ~
#
** to **
lyall@lyalls-pc:~
$ xfs_info /tmp
meta-data=/dev/mapper/vg-tmp isize=256 agcount=4, agsize=1310720 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=5242880, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=32768, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
I also updated my /etc/fstab from
LABEL=tmp /tmp xfs defaults,noatime 1 2
** to **
# Expendable, if power fail, possibility of loss of data, but no barriers improves throughput.
LABEL=tmp /tmp xfs defaults,noatime,logbsize=256k,barrier=0 1 2
Closing as workaround has been identified |
Created attachment 282283 [details] emerge --info During attempted emerge of libreoffice-3.4.2.3, a recursive chmod is performed after the extraction of the Impress source. The chmod hangs and any attempt to write anything to the filesystem hangs also. I have attempted the emerge twice, with exactly the same results each time. I have to kill my system using the alt-SysReq 'REISUB' key combo. xfs_check reports no issues with the file system. I use mdraid raid1 with LVM on the raid. I have /tmp as a separate LVM Volume to my other filesystems.