From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- hurd/translator/ext2fs.mdwn | 332 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 330 insertions(+), 2 deletions(-) (limited to 'hurd/translator/ext2fs.mdwn') diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index cfd09502..ba849cca 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2014 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -214,6 +214,334 @@ That would be a nice improvement, but only after writeback throttling is impleme tschwinge: well, thanks anyway ;) +## IRC, freenode, #hurd, 2014-02-11 + + task with pid 5 deallocating an invalid port 4622, most probably a + bug. + ext2fs + yes, i've seen this + e.g. when a passive translator starts + i guess it is in libfshelp/translator-list.c + + +## Inode Sizes, Fragment and Block Sizes + +### IRC, freenode, #hurd, 2014-02-12 + + this might be interesting and could make people not to fsck hurd + filesystem on linux: + start ext2fs: ext2fs: device:hd0s1 + ? + : panic: get_hypermetadata: inode size 256 isn't supported + (wait, also a bad typist) + well, if the file system was created from the hurd, or with -o + hurd, as it ought to be, you wouldn't have this problem + oh, good to know, especially before restoring :p + i suspect your mkfs command to have created an ext4 fs + nope mkfs.ext2 + hm ok, so it seems to create 256 size inodes by default there + i guess -o hurd would set some os-specific properties + it merely enforces a few restrictions + some predefined defaults + fragments and blocks are 4k + and apparently inodes are 128 bytes + because it can't support bigger values? is it worth working on remove + such restrictions? + probably not so far + certainly not the fragment/block size restriction + it matches the page size + larger inode sizes could be supported if they're dependencies for + other worthwhile features such as those someone would add in an ext4 + translator + + +## Linux' `CONFIG_EXT4_USE_FOR_EXT23` + +### IRC, freenode, #hurd, 2014-02-12 + + why the hell i have thousands of Inode 839, i_blocks is 248, should + be 256. Fix? yes + in all cases i_blocks should be +8 + and /dev/sda1: (There are 245635 inodes containing multiply-claimed + blocks.) + 10:50:08< gg0> start ext2fs: Hurd server bootstrap: + ext2fs[device:hd0s1] exec + That's exactly where my image boot hangs! + start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] exec + gnu_srs1: you might want to check that linux isn't using the ext4 + module to handle ext2 and ext3 filesystems + gnu_srs1: as I understand it the idea is that the ext4 module + treats them as ext2/ext3 filesystems, just avoiding code duplication from + having three separate modules for related filesystems, so it shouldn't + change it from ext2 at all, but it does do something strange with it + but I'm not sure if that's the case or if it's converting it to + ext4. last I heard Hurd doesn't support anything beyond ext2 + AliciaC: I did use ext2 when mounting from Linux: mount -t ext2 + /dev/loop0 /mnt + and when not mounted: e2fsck /dev/loop0 + gnu_srs1: I'd check the kernel config to be sure, + CONFIG_EXT4_USE_FOR_EXT23 must be disabled + you can use the ext4 driver for ext2 + that's not a problem here + the problem happens long before, when the file system gets + corrupted + you must understand why + I have done some testing on this, mounting a Hurd ext2 filesystem + with the ext4 module broke it for me, an easily repeated issue + mounting Debian's ext2 image and unmounting it with ext4 broke + it, resulting precisely in the kind of hang ups mentioned by gnu_srs1 and + gg0 + interesting + that's with a clean image with nothing corrupting it before hand, + tested to be working as well + ok so the ext4 driver must ignore hurd specific stuff + that's strange because i recall using it to perform small repairs + on darnassus and never had any issue + even on the root file syste + but my repairs were very quick and targetted + different linux versions maybe + when I was testing it I didn't even need to do anything in the + filesystem to trigger the issue, just mount and unmount + I repaired filesystems before like this, has something happened + with later versions of Linux? + One of my boxes is ext3 (probably worked before) another ext4 + (the one breaking things, but worked before) + ext3 and ext4 box: CONFIG_EXT4_USE_FOR_EXT23=y same kernel + 3.12-1.amd64 + what about mounting with bs=4096 (used by hurd) + -t ext2 should work fine + just don't use the ext4 driver if in doubt + no difference between specifying -t or not, in both cases EXT4-fs + (sda1): mounting ext2 file system using the ext4 subsystem + hmm + you're screwed then ; + ;p + or maybe -t ext3 .. :) + although i suspect ext4 would be used then too + linux-image-3.2.0-4-amd64: + /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko + wheezy still has it. then something between 3.2.0 and 3.13(?) removed + it + check the config file + i mean ext2 module + check if the config file enables it + It's not: # CONFIG_EXT2_FS is not set + 14:42 < gg0> wheezy still has it. then something between 3.2.0 and + 3.13(?) removed it + how about retrying what you did without ever mounting from linux ? + gg0: it wasn't clear enough that you meant removed from + configuration + (for example, it could have been blacklisted) + or present not as a module + maybe yes, although it's unusual to see generic kernels embedding + file systems these days + the CONFIG_EXT4_USE_FOR_EXT23 option isn't available if either + ext2 or ext3 are enabled though, even just as loadable modules + The ext2 and ext3 modules were there in 3.10-3, not in 3.12-1 + (14:48:59) : It's not: # CONFIG_EXT2_FS is not set -- + 3.12-1 + https://bugs.debian.org/731072 + * gg0 rsync'ing back to new fs with 3.10 kernel + seems like this bug was archived without being closed?? + someone should produce a testcase and file another one btw + but that bug was for files systems up to 4MB, not 4GB? + i pasted it just because submitter talks about config option in + question and when was enabled + don't we want to thank AliciaC who pointed it out and who could + precisely file a bug? :) + filed http://bugs.debian.org/738758 + gg0: thanks + AliciaC: and thanks too + + +### IRC, freenode, #hurd, 2014-02-13 + + gg0: Did you create and test with an ext2 Linux image too on + 3.10/3.12? + here is a diff: http://paste.debian.net/81837/ + visible differences: Filesystem features:filetype (linux only) + and Free inodes:1268(hurd) / 1269(linux) + between one created with -o Hurd and one created with -o Linux + (or no -o)? + AliciaC: -o Hurd and -b 4096 (no -o) + I wonder if that would show any interesting difference between an + untouched -o Hurd ext2 image and a copy of it that has been mounted with + the ext4 module + AliciaC: here: http://paste.debian.net/81857/ + there is a difference of one in the number of free inodes! + cf the number of free inodes for linux + gnu_srs: thanks :) though I don't know what to make of that, I + guess just adding an inode shouldn't break anything + wait, no, removing an inode? + bleh, too tired, read it wrong + this line should read:(11:37:48) srs: visible differences: + Filesystem features:filetype (linux only) and Free inodes:1268(linux) / + 1269(hurd) + There are differences in ext2.h and ext4.h in the Linux source + code wrt hurd1, hurd2 structs. + one change might be interesting: http://paste.debian.net/81864/ + gnu_srs: probably not + If not, where to look? + well, the first thing would be to create a (small) ext2 file + system, usable on the hurd, with a few files and directories + save it + mount it with the ext4 driver + and make a binary comparison + you could use a modified ext2fs translator to tell you exactly + what's wrong when loading the file system + and then look at the corresponding code in the ext4 driver + braunr: here is a binary diff of the unmounted and mounted e2fs + files: http://paste.debian.net/81896/ + gnu_srs1: i'm not going to analyze it + you are + :p + many of them can be removed: e.g. /mnt and bug000 + ? + many diff entries* + but why ? + you shouldn't have changed the content at all + If I don't add a file, the fs is not corrupted + this is with two vers small files created as in gg0s bug report + very* + ok + i guess checking the source code first and the binary diffs next + is easier + OK, I have to find out how the ext2fs files are organized. + I.e. reading mke2fs source code + no + read the ext4 driver + how a directory entry is created + how a directory is saved back on the block device + how any potential conversion could be triggered + k, will do + read about the ext2fs format if doing that first doesn't help + learning a file system is complicated and long + What is the inode size for Hurd/Linux? + probably 128 + same for both? + what is "Hurd/Linux" ? + on Hurd / on Linux + 128 on hurd, variable on linux + 128-512 i'd say + ext2 on linux + found it from dumpe2fs: 128 for both + no, it can vary on linux + although once a file system is built, the inode size cannot be + changed + k, the file created with mke2fs has 128 + + +## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.` + +### IRC, freenode, #hurd, 2014-02-19 + + "ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion + 'block' failed." in the console. + +[[user/Maksym_Planeta]] also has hit that one. + + wow oO + using debian hurd right ? + power cycling. + yes. + with hurd 1:0.5.git20140203-1 and glibc 2.17-98~1 ? + braunr: not sure how to check. + pere: dpkg -l | grep .. i suppose + gah, autofsck do not work.. :( + it does :( + unstable is easy to mess it seems + had to run fsck -y / manually... + i suspect you were using a corrupted file system at mount time + ah that + yes it is sometimes needed + but ext2 is reliable enough that only temporary files get their + way into lost+found + temporary/recently created + the crash you had, on the other hand, looks more serious + it seems like you mounted a corrupted file system + could be. + hurd v1:0.5.git20140203-1 and libc0.3 v2.17-98~1, it seem. + good + you shouldn't have such problems then, i suspect a mess up on your + part + but you're not the only one to have had weird file systems + problems lately + hah. I blame the hurd. :P + heh :) + gah, another crash. :( + Oo + same assertion ? + same place, or almost the same place. + yes. + hm + same crash. :( + what kind of machine do you run the hurd on ? + kvm + how much memory ? + 1G + did you see if the system was swapping ? + no idea. + i suggest always running top/htop on the hurd ;p + and monitor memory usage closely + unless pere lately mounted/fsck'ed fs in question with a recent linux + kernel, there should not be particular problems + it definitely doesn't look like it was mounted by an ext4 driver, + no + which means it's something else entirely and this is scary + I didn't. I fetched the prebuild image, upgraded it, switched it to + sysvinit and started working. + sorry i can't be of more help about that + ext2fs has been quite solid on my machines for a long time :( + there are known assertions that trigger under some special + pressure, but that's not what you're having here + pere: anything particular in fstab ? + nope, have not touched /etc/fstab. + hm stupid question + are you sure it's not full ? + nothing look full to me. + neither the disk nor the host file system. + + +### IRC, freenode, #hurd, 2014-02-20 + + braunr: do you remember my ext2fs crash from yesterday? I could + avoid it by interrupting the triggering build and running sync once in a + while. and it show up again if I do not sync in between. :) + ? + are you sure you're not swapping ? + I have no idea. still. :) + again, i recommend you run top/htop and monitor that + pere: is your patch needed to trigger the assertion ? + +[[open_issues/ti-rpc_then_nfs]]. + + braunr: well, without it, the package do not build, so yeah. :) + ok + tested again, and is not swapping. 850MB free memory. + ok + so this might be a real file system bug + let me see + pere: libtirpc built fine here .. + pere: do you have a separate /home partition ? + or any separate file system for builds + braunr: nope, everything on / + pere: i wouldn't recommend that + there very probably are bugs in the file system code and using + separate partitions is a way to alleviate them + + +## `ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion `!diskfs_readonly' failed.` + +### IRC, freenode, #hurd, 2014-02-22 + + login: init: notifying pfinet of shutdown...init: notifying tmpfs + none of shutdown...init: notifying tmpfs none of shutdown...init: + notifyi. + ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: + Assertion `!diskfs_readonly' failed. + In tight loop: hit ctl-alt-del to reboot + + # Documentation * -- cgit v1.2.3