[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

More brtfs reporting (was: Re: Filesystem recommendations)

On Monday 03 May 2010 12:10:24 Boyd Stephen Smith Jr. wrote:
> On Monday 26 April 2010 16:34:38 Boyd Stephen Smith Jr. wrote:
> > It doesn't appear to be a file system issue, but rather a problem with
> > the initramfs scripts.  It could also be rooted in my configuration.  I
> > know that my "root=" kernel parameter has to differ from the device name
> > in my /etc/fstab in order to get the initramfs to correctly initialize
> > LVM.
> I wanted to report that I was able to diagnose and solve this.  The problem
> was that /lib/udev/vol_id in my initramfs could not identify a btrfs file
> system, which caused the scripts to try and mount the root file system
>  using '-t unknown' as part of the command-line arguments.
> I upgraded initramfs-tools and udev to the Sid versions.  This should cause
>  a initramfs rebuild as part of the postinst, but if it doesn't do so on
>  your system, be sure to run (update-initramfs -k all -u).  Now my system
>  boots unattended with a btrfs '/'.
> So, at this time, btrfs can be used for non-'/' file systems with the tools
> from lenny-backports.  However, newer udev/initramfs-tools are required to
> boot with a btrfs '/'.  I hope they are included in the Squeeze release.  I
> have not, and probably will not test a btrfs '/boot'.
> I have also been encountering issues with suspend and resume on this new
> install.  I don't currently believe these are btrfs-related, either, but
>  fair warning.

They were, again, not btrfs related.

Initially mouse and keyboard were mostly dying on resume from RAM. (Alt+SysRq 
continued to work.)  Upgrading acpid to lenny-backports resolved this issue 
for the most part.

After that, the framebuffer was corrupted on resume from RAM.  If I restarted 
X through Alt+SysRq+K (I use kdm), I could continue to use X, but all the 
other virtual consoles were unusable.  I believed this to be an issue with 
xserver-xorg-video-intel, so I upgraded it to testing.

At this point, normal booting would hang the GPU when starting kdm; no chance 
to address suspend/resume.  Some troubleshooting indicated that if the vbesave 
init script from acpi-support were run prior to the kdm init script, that 
would cause the hang.  If the vbesave init script was not run, the system 
operated normally.

I purged acpi-support, since it was not a strong dependency of anything 
installed on the system.

Boot worked normally.  Suspend to RAM / resume works.  Suspend to disk / 
resume works.  Suspend to both (manually running /usr/sbin/s2both) and resume 
(from RAM) works.

As you might guess, there were a number of unclean reboots during this time.  
btrfs never had issues that prevented booting.  The journal replay / recovery 
is a bit less verbose that reiserfs and ext3, but it did occur and had to make 
some of the same corrections ("unlinking 27 orphans").  At one point, I did 
slightly suspect btrfs, so I ran a btrfsck while the file system was mounted. 
It could also benefit from being slightly more verbose, but it completed 
fairly quickly and reported no errors.  I also did an on-line defragment of 
the whole file system around the same time.  It took longer than I would like, 
since it gave no progress indication; again, more verbosity (or at least an 
*option*) would be appreciated.
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss@iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: