ext2fs translator from the upstream Hurd code base can only handle file
systems with sizes of less than roughly 2 GiB.
Ognyan Kulev, Supporting Large ext2 File Systems in the Hurd, 2005, at FOSDEM
Ognyan Kulev, large stores
Ognyan's patch lifts this limitation (and is being used in the
Debian GNU/Hurd distribution), but it introduces another
ext2fs then only supports block sizes of 4096 bytes.
Smaller block sizes are commonly automatically selected by
mke2fs when using
small backend stores, like floppy devices.
IRC, freenode, #hurd, 2012-06-30
<braunr> at least having the same api in the debian package and the git source would be great (in reference to the large store patch ofc) <youpi> braunr: the api part could be merged perhaps <youpi> it's very small apparently <antrik> braunr: the large store patch is a sad story. when it was first submitted, one of the maintainers raised some concerns. the other didn't share these (don't remember who is who), but the concerned one never followed up with details. so it has been in limbo ever since. tschwinge once promised to take it up, but didn't get around to it so far. plus, the original author himself mentioned once that he didn't consider it finished... <youpi> antrik: it's clearly not finished <youpi> there are XXXs here and there <braunr> it's called an RC1 and RC2 is mentioned in the release notes <antrik> youpi: well, that doesn't stop most other projects from commiting stuff... including most emphatically the original Hurd code :-) <youpi> what do you refer to my "that" ? :) <braunr> "XXX" <youpi> right <youpi> at the time it made sense to delay applying <youpi> but I guess by nowadays standard we should just as well commit it <youpi> it works enough for Debian, already <youpi> there is just one bug I nkow about <youpi> the apt database file keeps haveing the wrong size, fixed by e2fsck <pinotree> youpi: remember that patch should be fixed in the offset declaration in diskfs.h <youpi> I don't remember about that <youpi> did we fix it in the debian package? <pinotree> nope <youpi> you had issues when fixing it, didn't you? <youpi> (I don't remember where I can find the details about this) <pinotree> i changed it, recompiled hurd and installed it, started a perl rebuild and when running one of the two lfs tests it hard locked the vm after ext2fs was taking 100% cpu for a bit <pinotree> i don't exclude i could have done something stupid on my side though <youpi> or there could just be actual issues, uncovered here <youpi> which can be quite probable
IRC, freenode, #hurd, 2013-03-19
<braunr> youpi: i'm back on polishing the large store patch <braunr> did you remember seeing something else than the bzero/memset out-of-scope changes ? <braunr> (i mean, readily noticeable) <youpi> I don't remember <braunr> ok <braunr> the original code already assumes mmap succeeds <braunr> is it ok to consider the patch can do the same ? <youpi> I'd say so <braunr> ok <braunr> youpi: actually, it looks like a good part of the patch isn't related to large stores <braunr> for example, in ext2fs/inode.c, there are calls to dino_ref/dino_deref <youpi> hum <braunr> i'm not sure at all these have anything to do with handling large stores <youpi> but dino_ref is introduced by this patch, isn't it? <braunr> it replaces dino <youpi> yes, it replaces it because the dino() approach can't work beyond 2GiB <braunr> i see <braunr> youpi: i'd like to replace the recursive call to disk_cache_block_ref with a goto, is that fine with you ? <youpi> looks ok to me <youpi> better than relying on tail recursion <braunr> that's the idea :)
libpager API change
IRC, freenode, #hurd, 2013-03-04
<braunr> youpi: i don't remember exactly your answer when i asked about considering the ext2 large store patch for merging <youpi> there's just an API change that it introduces <youpi> but otherwise I'd say we should just do it <braunr> ok <youpi> I've just checked the API change again <youpi> it's simply adding a notify_on_evict parameter <youpi> and a pager_notify_evict callback <braunr> yes <youpi> I'd say we mostly need to polish this <youpi> ah, there is the same parameter on diskfs_start_disk_pager
IRC, freenode, #hurd, 2013-04-23
<braunr> and i'm working again on the ext2fs large store patch <braunr> i finished separating the libpager interface change from the rest, as Thomas suggested, so a new version should be ready soon
IRC, freenode, #hurd, 2013-03-04
<braunr> youpi: do we want EXT2FS_DEBUG defined upstream ? <youpi> I don't really have an opinion on this <youpi> stuffing it in the large store patch is not good of course <youpi> I wonder whether we want it by default. <braunr> it is currently defined by the patch <braunr> (in the debian package i mean) <youpi> I've just seen that yes <braunr> i won't include it upstream, and if we decide to keep this behaviour, we can add a patch just for that <braunr> or a define <braunr> err <braunr> a configure option <youpi> ok
IRC, freenode, #hurd, 2012-10-08
<braunr> btw, how about we increase our ext2 sync interval to 30 seconds, like others do ? <braunr> not really because others do it that way, but because it severely breaks performance on the hurd <braunr> and 30 seems like a reasonable amount (better than 5 at least)
That would be a nice improvement, but only after writeback throttling is implemented.