summaryrefslogtreecommitdiff
path: root/hurd/translator/ext2fs.mdwn
blob: 13a1d9ecbf5a2d83145bf5f06be2aa85481d81b1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 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
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]


# Implementation

  * [[filetype]] option

  * [[Hurd-specific_extensions]]

  * [[Page_cache]]

  * [[metadata_caching]]

  * [[internal_allocator]]


## Large Stores

The `ext2fs` translator from the upstream Hurd code base can only handle file
systems with sizes of less than roughly 2 GiB.

[[!tag open_issue_hurd]]


### Ognyan's Work

  * Ognyan Kulev, [[*Supporting Large ext2 File Systems in the
    Hurd*|ogi-fosdem2005.mgp]], 2005, at FOSDEM

  * Ognyan Kulev, [[large_stores]]

  * <http://kerneltrap.org/node/4429>

Ognyan's patch lifts this limitation (and is being used in the
[[Debian_GNU/Hurd_distribution|running/debian]]), but it introduces another
incompatibility: `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


## Sync Interval

[[!tag open_issue_hurd]]


### 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)


# Documentation

  * <http://e2fsprogs.sourceforge.net/ext2.html>

  * <http://www.nongnu.org/ext2-doc/>