Hello list, What would be a good number for the blocksize of an ext3 root-filesystem. My root-fs is 4.7 Gb and it keeps everything instead of home. After installation of crux and some additional packages (linux, gnuplot, tetex, prolog, xemacs, lmbench) and keeping the sources - there are 3.5 Gb in use (2.0 Gb for sources where only tetex takes 865 Mb). Are these common values? Is it possible that these numbers are too big and that this is due to my blocksize? I guess i have a default value... A directory node taks 4k. Is this my blocksize? What would be a good value? How do i figure out the exact value? How is the blocksize related to the pagesize? Do they have to be equal? Is there a problem with a too low blocksize, is there any? Please help.. matthias pfeifer PS: Is there a way to search the list-archive?
PS: Is there a way to search the list-archive? The mailing list is also archived at gmane.org, although it wasn't
Hi, On Thu, Aug 31, 2006 at 23:17:04 +0200, Matthias Pfeifer wrote: [...] listed on http://crux.nu/Main/MailingLists It is now, and you can browse and search here: http://news.gmane.org/gmane.linux.distributions.crux.general HTH, Johannnes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
2006/8/31, Johannes Winkelmann <jw@smts.ch>:
Hi,
PS: Is there a way to search the list-archive? The mailing list is also archived at gmane.org, although it wasn't
On Thu, Aug 31, 2006 at 23:17:04 +0200, Matthias Pfeifer wrote: [...] listed on http://crux.nu/Main/MailingLists It is now, and you can browse and search here: http://news.gmane.org/gmane.linux.distributions.crux.general
HTH, Johannnes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Thanks Johannes, Sorry that i have to continue this dead thread. But i am still struggling with my file-system. Ok, I ignored the recommendation from the handbook. But i keep moving. I want to go to reiserfs for some reasons and prepared a partition with "mkreiserfs -b 512 /dev/hda4" however mounting the partition with "mount /dev/hda4 /mnt" gives me a "floating point exception". Is there anything i can do to avoid this? The crux list has no reference to this and doing a google search on the topic seems to give only a bunch of completely unrelated links. gdb gives me a backtrace with #0 blkid_llseek () from /lib/libblkid.so.1 #1 blkid_verify () from /lib/libblkid.so.1 #2 blkid_get_dev () from /lib/libblkid.so.1 #3 blkid_get_tag_value () from /lib/libblkid.so.1 #4 error () Is there somthing wrong in my system? I can hardly imagine what that might be... My kernel? My libblkid.so.1? My kernel is self-compiled. libblkid.so.1 i never touched... thanks for any help... Matthias
Hi Matthias, On Tue, Sep 05, 2006 at 21:38:26 +0200, Matthias Pfeifer wrote: [...]
Sorry that i have to continue this dead thread. But i am still struggling with my file-system. Ok, I ignored the recommendation from the handbook. But i keep moving. I want to go to reiserfs for some reasons and prepared a partition with
"mkreiserfs -b 512 /dev/hda4"
however mounting the partition with
"mount /dev/hda4 /mnt"
gives me a "floating point exception". Reproducable here and by others on IRC:
Is there anything i can do to avoid this? The crux list has no reference to this and doing a google search on the topic seems to give only a bunch of completely unrelated links. It is also fairly off topic here. However, for the sake of having it archived and hopefully retrievable via google for the rest of the world, here we go :-).
gdb gives me a backtrace with
#0 blkid_llseek () from /lib/libblkid.so.1 #1 blkid_verify () from /lib/libblkid.so.1 #2 blkid_get_dev () from /lib/libblkid.so.1 #3 blkid_get_tag_value () from /lib/libblkid.so.1 #4 error () If you build a debug build of e2fsprogs (which provides libblkid), you'll get a somewhat better backtrace:
#0 0xb7f0c0f4 in probe_reiserfs (probe=0xbf8594b8, id=0xb7f0f870, buf=0x80697c0 "\200R¨\004ú÷§\004\001\020") at probe.c:425 425 if (id->bim_kboff/(blocksize>>10) > blkid_le32(rs->rs_journal_block)) (gdb) where #0 0xb7f0c0f4 in probe_reiserfs (probe=0xbf8594b8, id=0xb7f0f870, buf=0x80697c0 "\200R¨\004ú÷§\004\001\020") at probe.c:425 #1 0xb7f0ca0e in blkid_verify (cache=0x80588a0, dev=0x8059770) at probe.c:822 #2 0xb7f0a4b4 in blkid_get_dev (cache=0x80588a0, devname=0x8059750 "/dev/sda5", flags=<value optimized out>) at devname.c:82 #3 0xb7f0d367 in blkid_get_tag_value (cache=0x80588a0, tagname=0x40 <Address 0x40 out of bounds>, devname=0x8059750 "/dev/sda5") at resolve.c:45 #4 0x0804f838 in error () lib/blkid/probe.c [1] line 425 reads: if (id->bim_kboff/(blocksize>>10) > blkid_le32(rs->rs_journal_block)) Now, if blocksize is 512, blocksize>>10 is 0. This explains the problem you're seeing. That said, it's not possible to use a blocksize of 512 with the current release of e2fsprogs. Whether this is intentional or not is unclear to me at the moment. HTH, Johannes References: 1. http://thunk.org/hg/e2fsprogs/?f=20ad07a17a5a;file=lib/blkid/probe.c -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Hey, On Tue, Sep 05, 2006 at 23:07:53 +0200, Johannes Winkelmann wrote: [...]
Now, if blocksize is 512, blocksize>>10 is 0. This explains the problem you're seeing. That said, it's not possible to use a blocksize of 512 with the current release of e2fsprogs. Whether this is intentional or not is unclear to me at the moment. Searching a bit further, I found the following patch: http://ftp.suse.com/pub/people/hvogel/RPMS/e2fsprogs/e2fsprogs-probe_reiserf...
With this patch applied, mounting the partition works, however since I can't judge whether this is causing any further problems, some posts I've read talk about performance issues and both mkreiserfs and mount commands took extremely long (even for reiser) when using such small blocksizes I decided to keep core/e2fsprogs in sync with the upstream release. Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Hi, 2006/9/5, Johannes Winkelmann <jw@smts.ch>:
Hey,
On Tue, Sep 05, 2006 at 23:07:53 +0200, Johannes Winkelmann wrote: [...]
Now, if blocksize is 512, blocksize>>10 is 0. This explains the problem you're seeing. That said, it's not possible to use a blocksize of 512 with the current release of e2fsprogs. Whether this is intentional or not is unclear to me at the moment. Searching a bit further, I found the following patch: http://ftp.suse.com/pub/people/hvogel/RPMS/e2fsprogs/e2fsprogs-probe_reiserf...
With this patch applied, mounting the partition works, however since I can't judge whether this is causing any further problems, some posts I've read talk about performance issues and both mkreiserfs and mount commands took extremely long (even for reiser) when using such small blocksizes I decided to keep core/e2fsprogs in sync with the upstream release.
Hi Johannes, Thanks for the hints. I agree with you and will better not try out obscure configurations. Not only because i still suffer from a very negative experience that is strongly related to my harddisk... matthias
participants (2)
-
Johannes Winkelmann -
Matthias Pfeifer