Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
New filesystem: Btrfs! (cont.)
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4 ... 9, 10, 11  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3793

PostPosted: Wed Aug 11, 2010 12:47 pm    Post subject: Reply with quote

Quote:
I know with ZFS, periodic scrubbing is recommended. Perhaps something similar with btrfs?


could be. If this thing beaks again it should happen in a few months, will try to diagnose it a bit better then.

Does anyone know if btrfs actually can handle manually dropping inodes/dentry caches ? I suppose it does but i was experimenting with other stuff and if i remember correctly this started to happen exactly after doing this.

Quote:
will I gain anything at all by having laptop-mode enabled too?


im not sure but i think that laptop mode stuff is usefull for spinning down the traditional drives and this is not your case.

Quote:
How big's /usr/portage with compression?


i dont have /usr/portage on a separate partition anymore in this lappy but if i recall correctly it went to under 80 Mbs. That was with compress-force enabled and after excluding many packages in the tree from syncing. If you enable compress-force it will try to compress without exception, some have even reported performance gains when enabling this.

Quote:
Can I do anything useful with subvolumes on a setup like this?


it depends, i havent played much with this and the raid options (yet), maybe more interessting to play with the snapshots option.

cheers
Back to top
View user's profile Send private message
kolcon
Tux's lil' helper
Tux's lil' helper


Joined: 21 Sep 2007
Posts: 96
Location: Europe, CZ

PostPosted: Fri Aug 27, 2010 7:36 am    Post subject: btrfs-progrs-9999 failing compile Reply with quote

Hello,

Since about 1 month the btrfs-progs-9999 do not compile.

Code:

btrfsck.o: In function `maybe_free_inode_rec':
btrfsck.c:(.text+0x16c7): undefined reference to `S_ISDIR'
btrfsck.c:(.text+0x16fb): undefined reference to `S_ISREG'
btrfsck.c:(.text+0x17be): undefined reference to `S_ISREG'
btrfsck.c:(.text+0x1854): undefined reference to `S_ISLNK'
btrfsck.c:(.text+0x188c): undefined reference to `S_ISLNK'
collect2: ld returned 1 exit status
make: *** [btrfsck] Error 1
emake failed


I have seen a patch in the btrfs mailing list on 18th June. So is it ebuild problem?
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Fri Aug 27, 2010 10:53 am    Post subject: Re: btrfs-progrs-9999 failing compile Reply with quote

kolcon wrote:
Hello,

Since about 1 month the btrfs-progs-9999 do not compile.

Code:

btrfsck.o: In function `maybe_free_inode_rec':
btrfsck.c:(.text+0x16c7): undefined reference to `S_ISDIR'
btrfsck.c:(.text+0x16fb): undefined reference to `S_ISREG'
btrfsck.c:(.text+0x17be): undefined reference to `S_ISREG'
btrfsck.c:(.text+0x1854): undefined reference to `S_ISLNK'
btrfsck.c:(.text+0x188c): undefined reference to `S_ISLNK'
collect2: ld returned 1 exit status
make: *** [btrfsck] Error 1
emake failed


I have seen a patch in the btrfs mailing list on 18th June. So is it ebuild problem?


nope - most probably upstream problem

it also doesn't compile for me (hint: according to the mailing list it's still under heavy development and not ready yet)

who needs fsck anyway with btrfs :twisted:
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
ToeiRei
Veteran
Veteran


Joined: 03 Jan 2005
Posts: 1191
Location: Austria

PostPosted: Sat Aug 28, 2010 9:24 am    Post subject: Reply with quote

Please tell me the USE-Flags you use for compiling. Is the Flag 'acl' active?
_________________
Please stand by - The mailer daemon is busy burning your messages in hell...
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sat Aug 28, 2010 10:30 am    Post subject: Reply with quote

ToeiRei wrote:
Please tell me the USE-Flags you use for compiling. Is the Flag 'acl' active?


yes and no:

it still fails with acl and debug-utils flags enabled/disabled:

Quote:
USE="-debug-utils -acl" CFLAGS="-O2 -march=core2 -mtune=core2 -pipe" CXXFLAGS="${CFLAGS}"


gcc was switched to vanilla-behavior, it also failed when disabling fortify (-U_FORTIFY_SOURCE) or using other LDFLAGS

the following was with acl and debug-utils disabled:
Quote:
>>> Emerging (1 of 1) sys-fs/btrfs-progs-9999
* CPV: sys-fs/btrfs-progs-9999
* REPO: gentoo
* USE: amd64 elibc_glibc kernel_linux multilib userland_GNU
>>> Unpacking source...
* GIT update -->
* repository: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
* at the commit: 075587c96c2f39e227847d13ca0ef305b13cd7d3
* branch: master
* storage directory: "/home/distfiles/git-src/btrfs-progs"
Cloning into /var/tmp/portage/sys-fs/btrfs-progs-9999/work/btrfs-progs-9999...
done.
>>> Unpacked to /var/tmp/portage/sys-fs/btrfs-progs-9999/work/btrfs-progs-9999
>>> Source unpacked in /var/tmp/portage/sys-fs/btrfs-progs-9999/work
>>> Compiling source in /var/tmp/portage/sys-fs/btrfs-progs-9999/work/btrfs-progs-9999 ...
make -j9 CC=x86_64-pc-linux-gnu-gcc 'CFLAGS=-O2 -march=core2 -mtune=core2 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' all
bash version.sh
ls ctree.c
ls disk-io.c
ls radix-tree.c
ctree.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.ctree.o.d,-MT,ctree.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c ctree.c
disk-io.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.disk-io.o.d,-MT,disk-io.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c disk-io.c
radix-tree.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.radix-tree.o.d,-MT,radix-tree.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c radix-tree.c
ls extent-tree.c
ls print-tree.c
ls root-tree.c
extent-tree.c
print-tree.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.extent-tree.o.d,-MT,extent-tree.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c extent-tree.c
root-tree.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.print-tree.o.d,-MT,print-tree.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c print-tree.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.root-tree.o.d,-MT,root-tree.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c root-tree.c
ls dir-item.c
ls file-item.c
dir-item.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.dir-item.o.d,-MT,dir-item.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c dir-item.c
file-item.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.file-item.o.d,-MT,file-item.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c file-item.c
ls inode-item.c
inode-item.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.inode-item.o.d,-MT,inode-item.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c inode-item.c
ls inode-map.c
inode-map.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.inode-map.o.d,-MT,inode-map.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c inode-map.c
ls crc32c.c
crc32c.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.crc32c.o.d,-MT,crc32c.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c crc32c.c
ls rbtree.c
rbtree.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.rbtree.o.d,-MT,rbtree.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c rbtree.c
ls extent-cache.c
extent-cache.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.extent-cache.o.d,-MT,extent-cache.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c extent-cache.c
ls extent_io.c
extent_io.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.extent_io.o.d,-MT,extent_io.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c extent_io.c
ls volumes.c
volumes.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.volumes.o.d,-MT,volumes.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c volumes.c
ls utils.c
utils.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.utils.o.d,-MT,utils.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c utils.c
ls btrfs-list.c
btrfs-list.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfs-list.o.d,-MT,btrfs-list.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfs-list.c
ls btrfsctl.c
btrfsctl.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfsctl.o.d,-MT,btrfsctl.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfsctl.c
ls mkfs.c
ls debug-tree.c
mkfs.c
debug-tree.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.mkfs.o.d,-MT,mkfs.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c mkfs.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.debug-tree.o.d,-MT,debug-tree.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c debug-tree.c
ls btrfs-show.c
btrfs-show.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfs-show.o.d,-MT,btrfs-show.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfs-show.c
ls btrfs-vol.c
btrfs-vol.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfs-vol.o.d,-MT,btrfs-vol.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfs-vol.c
ls btrfsck.c
btrfsck.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfsck.o.d,-MT,btrfsck.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfsck.c
ls btrfs.c
btrfs.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfs.o.d,-MT,btrfs.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfs.c
ls btrfs_cmds.c
btrfs_cmds.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfs_cmds.o.d,-MT,btrfs_cmds.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfs_cmds.c
ls btrfs-map-logical.c
btrfs-map-logical.c
x86_64-pc-linux-gnu-gcc -Wp,-MMD,./.btrfs-map-logical.o.d,-MT,btrfs-map-logical.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -march=core2 -mtune=core2 -pipe -c btrfs-map-logical.c
cd man; make
make[1]: Entering directory `/var/tmp/portage/sys-fs/btrfs-progs-9999/work/btrfs-progs-9999/man'
gzip -n -c mkfs.btrfs.8.in > mkfs.btrfs.8.gz
gzip -n -c btrfsctl.8.in > btrfsctl.8.gz
gzip -n -c btrfsck.8.in > btrfsck.8.gz
gzip -n -c btrfs-image.8.in > btrfs-image.8.gz
gzip -n -c btrfs-show.8.in > btrfs-show.8.gz
gzip -n -c btrfs.8.in > btrfs.8.gz
make[1]: Leaving directory `/var/tmp/portage/sys-fs/btrfs-progs-9999/work/btrfs-progs-9999/man'
btrfsck.c: In function ‘maybe_free_inode_rec’:
btrfsck.c:323:2: warning: implicit declaration of function ‘S_ISDIR’
btrfsck.c:328:2: warning: implicit declaration of function ‘S_ISREG’
btrfsck.c:328:2: warning: implicit declaration of function ‘S_ISLNK’
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o btrfsctl btrfsctl.o ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o -Wl,-O1 -Wl,--as-needed -luuid
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o mkfs.btrfs ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o mkfs.o -Wl,-O1 -Wl,--as-needed -luuid
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o btrfs-debug-tree ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o debug-tree.o -Wl,-O1 -Wl,--as-needed -luuid
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o btrfs-show btrfs-show.o ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o -Wl,-O1 -Wl,--as-needed -luuid
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o btrfs-vol btrfs-vol.o ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o -Wl,-O1 -Wl,--as-needed -luuid
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o btrfs btrfs.o btrfs_cmds.o \
ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o -Wl,-O1 -Wl,--as-needed -luuid
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o btrfs-map-logical ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfs-map-logical.o -Wl,-O1 -Wl,--as-needed -luuid
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -o btrfsck btrfsck.o ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o -Wl,-O1 -Wl,--as-needed -luuid
btrfsck.o: In function `maybe_free_inode_rec':
btrfsck.c:(.text+0x1306): undefined reference to `S_ISDIR'
btrfsck.c:(.text+0x1333): undefined reference to `S_ISREG'
btrfsck.c:(.text+0x13fb): undefined reference to `S_ISREG'
btrfsck.c:(.text+0x1462): undefined reference to `S_ISLNK'
btrfsck.c:(.text+0x1491): undefined reference to `S_ISLNK'
collect2: ld returned 1 exit status
make: *** [btrfsck] Error 1
emake failed
* ERROR: sys-fs/btrfs-progs-9999 failed:
* (no error message)
*
* Call stack:
* ebuild.sh, line 47: Called src_compile
* environment, line 2569: Called die
* The specific snippet of code:
* emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" all || die;
*
* If you need support, post the output of 'emerge --info =sys-fs/btrfs-progs-9999',
* the complete build log and the output of 'emerge -pqv =sys-fs/btrfs-progs-9999'.
* The complete build log is located at '/var/log/portage/sys-fs:btrfs-progs-9999:20100828-102852.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-fs/btrfs-progs-9999/temp/environment'.
* S: '/var/tmp/portage/sys-fs/btrfs-progs-9999/work/btrfs-progs-9999'

>>> Failed to emerge sys-fs/btrfs-progs-9999, Log file:

>>> '/var/log/portage/sys-fs:btrfs-progs-9999:20100828-102852.log'

* Messages for package sys-fs/btrfs-progs-9999:

* GIT update -->
* repository: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
* at the commit: 075587c96c2f39e227847d13ca0ef305b13cd7d3
* branch: master
* storage directory: "/home/distfiles/git-src/btrfs-progs"
* ERROR: sys-fs/btrfs-progs-9999 failed:
* (no error message)
*
* Call stack:
* ebuild.sh, line 47: Called src_compile
* environment, line 2569: Called die
* The specific snippet of code:
* emake CC="$(tc-getCC)" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" all || die;
*
* If you need support, post the output of 'emerge --info =sys-fs/btrfs-progs-9999',
* the complete build log and the output of 'emerge -pqv =sys-fs/btrfs-progs-9999'.
* The complete build log is located at '/var/log/portage/sys-fs:btrfs-progs-9999:20100828-102852.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-fs/btrfs-progs-9999/temp/environment'.
* S: '/var/tmp/portage/sys-fs/btrfs-progs-9999/work/btrfs-progs-9999'
*
* The following package has failed to build or install:
*
* (sys-fs/btrfs-progs-9999, ebuild scheduled for merge), Log file:
* '/var/log/portage/sys-fs:btrfs-progs-9999:20100828-102852.log'
*




so it's completely broken
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
ToeiRei
Veteran
Veteran


Joined: 03 Jan 2005
Posts: 1191
Location: Austria

PostPosted: Sat Aug 28, 2010 10:35 am    Post subject: Reply with quote

could you please send that to the btrfs mailing-list? I am sure Chris and the guys are interested in that report to fix it.
_________________
Please stand by - The mailer daemon is busy burning your messages in hell...
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Wed Sep 01, 2010 2:07 pm    Post subject: Reply with quote

It's curious how slow the pace of commits to the kernel git repository has become.

Here we are at 2.6.36_rc3, and not a single commit from the btrfs team for this kernel series. Usually, by the time rc3 rolls around, they don't like to see many new commits, mostly just bug fixes and regressions.

This is odd because I know there were at least several commits they wanted to get into 2.6.35, but were turned back by Linus (there were some additional timing issues for 2.6.35, see this LKML thread here: [GIT PULL] Btrfs updates for 2.6.35).

I would have thought at least those commits they had queued up for 2.6.35 would be in 2.6.36_rc* by now.

It would be really nice if they had a "btrfs-next" git repo to facilitate queuing up patches for the next release cycle.
Back to top
View user's profile Send private message
jormartr
Apprentice
Apprentice


Joined: 02 Jan 2008
Posts: 174

PostPosted: Sat Oct 30, 2010 12:50 am    Post subject: Reply with quote

Blog entry about btrfs stability

I did not understand exactly that about the failing raids on the blog, I do not know if he is talking in general, or saying that his tests include failing drives on raids ...
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Sat Oct 30, 2010 5:15 am    Post subject: Reply with quote

I'm not quite sure how you can assert that it's effectively stable in one paragraph, and then talk about all the wonderful patches that are coming in the 2.6.37 and 2.6.38 kernels in the next paragraph. :D
Back to top
View user's profile Send private message
jormartr
Apprentice
Apprentice


Joined: 02 Jan 2008
Posts: 174

PostPosted: Sat Oct 30, 2010 1:20 pm    Post subject: Reply with quote

Dont Panic wrote:
I'm not quite sure how you can assert that it's effectively stable in one paragraph, and then talk about all the wonderful patches that are coming in the 2.6.37 and 2.6.38 kernels in the next paragraph. :D


Ho, no, I have not any relation to that blog/entity, I am just posting it here, because I think it is on-topic, and maybe somebody is interested in reading it.

I agree with what you feel, but also, I have seen some interesting patches on the mailing list. I am interested in one that adds lzo support :D. Ok, it is no stability related, but I find that quite interesting.
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Sat Oct 30, 2010 1:31 pm    Post subject: Reply with quote

jormartr wrote:
Dont Panic wrote:
I'm not quite sure how you can assert that it's effectively stable in one paragraph, and then talk about all the wonderful patches that are coming in the 2.6.37 and 2.6.38 kernels in the next paragraph. :D


Ho, no, I have not any relation to that blog/entity

Lol, I should choose my words better. :)

By "you", I was really trying (unsuccessfully) to mean a broader "anybody in particular"
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sat Oct 30, 2010 3:15 pm    Post subject: Reply with quote

anyone using latest btrfs ?

I'd like to try out Chris Mason's git-tree on top of 2.6.36

how would I pull that tree into the stable 2.6.36 tree ?

unfortunately I'm not too experienced with git yet so I need some training wheels ;)

many thanks in advance

edit:

it's based on 2.6.36-tree so diffing the latest commit against the commit of 2.6.36 should suffice to get a patch:

https://forums.gentoo.org/viewtopic-p-6470403.html#6470403
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA

PostPosted: Sat Oct 30, 2010 6:55 pm    Post subject: Reply with quote

kernelOfTruth wrote:
anyone using latest btrfs ?

I'd like to try out Chris Mason's git-tree on top of 2.6.36

how would I pull that tree into the stable 2.6.36 tree ?

unfortunately I'm not too experienced with git yet so I need some training wheels ;)

many thanks in advance

edit:

it's based on 2.6.36-tree so diffing the latest commit against the commit of 2.6.36 should suffice to get a patch:

https://forums.gentoo.org/viewtopic-p-6470403.html#6470403
I am not sure what you mean by latest. The last changes in Mason's unstable tree are from Jul 2010.

If you mean vanilla 2.6.36, then I tried that on my laptop, although I swore off of BTRFS. And the result was pretty bad. Oops in BTRFS code after couple of suspend-resume cycles. Yikes!
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Sat Oct 30, 2010 9:40 pm    Post subject: Reply with quote

kernelOfTruth wrote:
anyone using latest btrfs ?

I've been trying to keep up with the patches, and have Chris Mason's git "scratch" branch (as of yesterday) incorporated into a 2.6.36 kernel.

He's already updated the scratch branch, and passed a set of patches on to Linus, so I'm out-of-date already.

So there's some fresh Btrfs patches in the official Linux kernel git repository now, but they are queued up for 2.6.37_rc1 (which isn't even out yet).

I'm pretty sure the recent set of patches will work fine with a 2.6.36 kernel since these patches were mostly developed around 2.6.35 and 2.6.36 kernels. But I need to look at the rest of the patches that were just added.

This set of changes is fairly sizeable (Total: (39) commits (+2430 lines/-546 lines)). It's good to see this much development going on.

There are some good improvements and fixes in this set of patches, but I still expect a steady stream of development for the immediate future.
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Oct 31, 2010 1:17 pm    Post subject: Reply with quote

devsk wrote:
I am not sure what you mean by latest. The last changes in Mason's unstable tree are from Jul 2010.

If you mean vanilla 2.6.36, then I tried that on my laptop, although I swore off of BTRFS. And the result was pretty bad. Oops in BTRFS code after couple of suspend-resume cycles. Yikes!


ouch 8O

in the past I also wanted to test it on my system partition but then I read about cumulative errors and data corruptions (I had data-corruption after a hardlock and reboot on my portage-partition, too)

so it's not really fail-proof yet

I meant the unstable tree with the latest changes: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=summary ;)

with that it feels much better now - there don't seem to be any stability enhancing patches though

Dont Panic wrote:
kernelOfTruth wrote:
anyone using latest btrfs ?

I've been trying to keep up with the patches, and have Chris Mason's git "scratch" branch (as of yesterday) incorporated into a 2.6.36 kernel.

He's already updated the scratch branch, and passed a set of patches on to Linus, so I'm out-of-date already.

So there's some fresh Btrfs patches in the official Linux kernel git repository now, but they are queued up for 2.6.37_rc1 (which isn't even out yet).

I'm pretty sure the recent set of patches will work fine with a 2.6.36 kernel since these patches were mostly developed around 2.6.35 and 2.6.36 kernels. But I need to look at the rest of the patches that were just added.

This set of changes is fairly sizeable (Total: (39) commits (+2430 lines/-546 lines)). It's good to see this much development going on.

There are some good improvements and fixes in this set of patches, but I still expect a steady stream of development for the immediate future.


yeah, it feels faster now - according to the btrfs mailing list there are still likely lots of functionality improvements in the near future :)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
ToeiRei
Veteran
Veteran


Joined: 03 Jan 2005
Posts: 1191
Location: Austria

PostPosted: Sun Oct 31, 2010 1:21 pm    Post subject: Reply with quote

I am sticking with the development code here too... but in my case, btrfs is not the biggest problem (/boot on ext2, rest btrfs subvolumes).
2.6.36 seems to cause more pain here while microcode updates of the cpu. But I can confirm that btrfs got pretty fast by now.
_________________
Please stand by - The mailer daemon is busy burning your messages in hell...
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA

PostPosted: Sun Oct 31, 2010 5:20 pm    Post subject: Reply with quote

ToeiRei wrote:
I am sticking with the development code here too... but in my case, btrfs is not the biggest problem (/boot on ext2, rest btrfs subvolumes).
2.6.36 seems to cause more pain here while microcode updates of the cpu. But I can confirm that btrfs got pretty fast by now.
Do you have some before and after benchmarks or is it subjectively "faster"?....:-D
Back to top
View user's profile Send private message
ToeiRei
Veteran
Veteran


Joined: 03 Jan 2005
Posts: 1191
Location: Austria

PostPosted: Sun Oct 31, 2010 7:01 pm    Post subject: Reply with quote

I compile a kernel on it which is a pretty Real World example.
2.6.36 on 'vanilla' compiles in about 10 minutes (and some seconds). The btrfs patches cut it down to 8 minutes (and some seconds)
_________________
Please stand by - The mailer daemon is busy burning your messages in hell...
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA

PostPosted: Sun Oct 31, 2010 7:54 pm    Post subject: Reply with quote

ToeiRei wrote:
I compile a kernel on it which is a pretty Real World example.
2.6.36 on 'vanilla' compiles in about 10 minutes (and some seconds). The btrfs patches cut it down to 8 minutes (and some seconds)
Kernel compiles are mostly CPU bound. I can't imagine a compile can have 20% gain with FS performance increases. I have never seen such gain in recent times (other than the hardware upgrade itself).

Are you sure it wasn't the cache effect when you ran it the second time e.g. you hadn't untarred the kernel sources in the first run freshly while you did untar for the second run loading the whole tree in cache.
Back to top
View user's profile Send private message
ToeiRei
Veteran
Veteran


Joined: 03 Jan 2005
Posts: 1191
Location: Austria

PostPosted: Sun Oct 31, 2010 9:48 pm    Post subject: Reply with quote

I didn't modify it all and had cold caches. On my laptop I can feel some changes due to the slow harddisk pretty bad.
_________________
Please stand by - The mailer daemon is busy burning your messages in hell...
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Mon Nov 01, 2010 5:20 pm    Post subject: Reply with quote

So, while we're chatting about it, what might be some examples of some decent command-line tests we can run to gauge filesystem speed, short of running bonnie++.

Maybe a 'time cp -r /usr/portage /tmp' or 'time cp -r /var/db/pkg /tmp'?

Of course all the simple tests will have built in limitations I suppose. Such as, the above example will change over time as your system updates.
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA

PostPosted: Mon Nov 01, 2010 5:48 pm    Post subject: Reply with quote

Dont Panic wrote:
So, while we're chatting about it, what might be some examples of some decent command-line tests we can run to gauge filesystem speed, short of running bonnie++.

Maybe a 'time cp -r /usr/portage /tmp' or 'time cp -r /var/db/pkg /tmp'?

Of course all the simple tests will have built in limitations I suppose. Such as, the above example will change over time as your system updates.
You need to keep a tar of portage or linux source and always use that. What I did was to create a tar (without compression) consisting of 5 copies of the linux source. I then drop caches, measure time to untar it, drop caches, measure time to tar it back, drop caches, untar it, measure time to 'du -sk' it, drop caches, measure time to 'find .' it. These 4 (tar, untar, du, find) operations are typical operations for me which determine the speed of the FS.

I keep that tar around (compressed) for tests.
Back to top
View user's profile Send private message
Enlight
Advocate
Advocate


Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)

PostPosted: Tue Nov 02, 2010 6:39 pm    Post subject: Reply with quote

devsk wrote:
Dont Panic wrote:
So, while we're chatting about it, what might be some examples of some decent command-line tests we can run to gauge filesystem speed, short of running bonnie++.

Maybe a 'time cp -r /usr/portage /tmp' or 'time cp -r /var/db/pkg /tmp'?

Of course all the simple tests will have built in limitations I suppose. Such as, the above example will change over time as your system updates.
You need to keep a tar of portage or linux source and always use that. What I did was to create a tar (without compression) consisting of 5 copies of the linux source. I then drop caches, measure time to untar it, drop caches, measure time to tar it back, drop caches, untar it, measure time to 'du -sk' it, drop caches, measure time to 'find .' it. These 4 (tar, untar, du, find) operations are typical operations for me which determine the speed of the FS.

I keep that tar around (compressed) for tests.


This is definitly not a good way to evaluate the fs performance. First of all tar is single threaded, therefore you won't test wether your fs is able or not to take a big load.

Second it advantages fs who rather to lay things as they come instead of spreading them to prevent files and directory fragmentation later.
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA

PostPosted: Tue Nov 02, 2010 6:58 pm    Post subject: Reply with quote

Enlight wrote:
devsk wrote:
Dont Panic wrote:
So, while we're chatting about it, what might be some examples of some decent command-line tests we can run to gauge filesystem speed, short of running bonnie++.

Maybe a 'time cp -r /usr/portage /tmp' or 'time cp -r /var/db/pkg /tmp'?

Of course all the simple tests will have built in limitations I suppose. Such as, the above example will change over time as your system updates.
You need to keep a tar of portage or linux source and always use that. What I did was to create a tar (without compression) consisting of 5 copies of the linux source. I then drop caches, measure time to untar it, drop caches, measure time to tar it back, drop caches, untar it, measure time to 'du -sk' it, drop caches, measure time to 'find .' it. These 4 (tar, untar, du, find) operations are typical operations for me which determine the speed of the FS.

I keep that tar around (compressed) for tests.


This is definitly not a good way to evaluate the fs performance. First of all tar is single threaded, therefore you won't test wether your fs is able or not to take a big load.

Second it advantages fs who rather to lay things as they come instead of spreading them to prevent files and directory fragmentation later.
That wasn't supposed to be a benchmark. Its supposed to be a set of operations which *I* need the filesystem to be good at for *me*. I don't care some filesystems are smarter for *me* and lay out stuff well (I say thank you dear FS!).
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA

PostPosted: Tue Nov 02, 2010 6:59 pm    Post subject: Reply with quote

BTW: that was supposed to avoid variables like compression speed, compiler speed etc. for testing the *same FS* over kernels.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4 ... 9, 10, 11  Next
Page 3 of 11

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum