On Wed, Feb 6, 2013 at 4:45 AM, Josef Bacik wrote:
> Ok so I think we've fixed this already, can you build btrfs-next and try
> mounting with that and see if it fixes the problem? Thanks,
Hi, Josef,
Is there any btrfs git compatible with kernel 3.7 and absorbs this
fix? So I can dkms it, I'm us
On Wed, Feb 6, 2013 at 3:35 AM, Josef Bacik wrote:
> Eesh can you fpaste this, it got wrapped by your mailer and I can't read it.
> Thanks,
Hi, Josef,
Of course, http://paste.opensuse.org/80508108
I at first thought pasting here may help archive. but Gmail sucks...sorry!
Marguerite
--
To unsub
Hi, cwillu,
I have my filesystems mounted with compress=lzo and inode_cache.
now the only problem is, I can't "btrfs filesystem defragment -c
/dev/sda5" which says:
earth:/home/marguerite # btrfs filesystem defragment -clzo /dev/sda5
ERROR: defrag range ioctl not supported in this kernel, please
On Sun, Oct 21, 2012 at 8:44 AM, cwillu wrote:
> Neither io_cache nor compression=lzo are options that exist. You
> probably meant compress=lzo for the first, but I really don't know
> what you wanted for io_cache (inode_cache? that's not really a
> performance thing)
>
> You need to check what
Hi,
I planned to boost my btrfs performance today. here some errors I met:
my 'btrfs filesystem show' result:
~ # btrfs filesystem show
failed to read /dev/sr0
Label: none uuid: 9b9aa9d9-760e-445c-a0ab-68e102d9f02e
Total devices 1 FS bytes used 36.59GB
devid1 size 49.52GB us
On Sat, Oct 20, 2012 at 2:35 AM, cwillu wrote:
> Without space_cache (once), btrfs has to repopulate that information
> the slow way every mount; with it, it can just load the data from the
> last unmount (modulo some consistency checks).
>
> The setting is sticky, so you don't actually need it in
On Sat, Oct 20, 2012 at 2:26 AM, cwillu wrote:
> That would work, but it's only necessary to mount with it once (and
> it's probably been done already with /home), hence the -o
> remount,space_cache
Now my kernel loads in 10s, another 4s for userspace...then -.mount
and all the systemd services.
On Sat, Oct 20, 2012 at 12:55 AM, cwillu wrote:
> It appears space_cache isn't enabled on your rootfs; can you do a
> "mount / -o remount,space_cache", sync a couple times, make some
> coffee, and then reboot, and see if it's better?
>
> You should see two instances of "btrfs: disk space caching i
On Sat, Oct 20, 2012 at 12:55 AM, cwillu wrote:
> It appears space_cache isn't enabled on your rootfs; can you do a
> "mount / -o remount,space_cache", sync a couple times, make some
> coffee, and then reboot, and see if it's better?
>
> You should see two instances of "btrfs: disk space caching i
On Fri, Oct 19, 2012 at 11:41 PM, cwillu wrote:
> Also, next time just put the output directly in the email, that way
> it's permanently around to look at and search for.
Hi,
I did it. here's my dmesg:
[ 25.623660] SysRq : Show Blocked State
[ 25.623667] taskPC sta
On Fri, Oct 19, 2012 at 11:41 PM, cwillu wrote:
> You need to hit alt-sysrq-w during the slowness you're trying to
> instrument; the pastebin is from an hour later.
>
> Also, next time just put the output directly in the email, that way
> it's permanently around to look at and search for.
Thanks
On Thu, Oct 18, 2012 at 9:28 PM, Chris Mason wrote:
> If it isn't the free space cache, it'll be a fragmentation problem. The
> easiest way to tell the difference is to get a few sysrq-w snapshots
> during the boot.
Hi, Chris,
with some help from openSUSE community, I learnt what's sysrq
snapsh
On Thu, Oct 18, 2012 at 9:28 PM, Chris Mason wrote:
>
> Usually when btrfs is slow to mount, or slow right after a mount it is
> because we're regenerating the free space cache. This is slow enough
> that you should be able to see the free space cache threads active even
> after the initial boot
Hi, all,
I ran into a situation that no useful information can be found over
the internet...
I'm using 3.6.2 + btrfs git compiled using dkms, and I have a 300GB
btrfs /home and 50GB btrfs /:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 195352
14 matches
Mail list logo
