Hi,
I just started to use ext4 and wondered if there is some git/svn/hg/etc
repository for the e2fsprogs-interim? And, is there any timeframe when
ext4 support will make it into the mainline tree for e2fsprogs? Will
there be a mkfs.ext4 too?
Thanks,
Christian.
--
BOFH excuse #266:
All of the packets are empty.
On Tue, Nov 20, 2007 at 01:42:58AM +0100, Christian Kujau wrote:
> Hi,
>
> I just started to use ext4 and wondered if there is some git/svn/hg/etc
> repository for the e2fsprogs-interim? And, is there any timeframe when ext4
> support will make it into the mainline tree for e2fsprogs? Will
> there be a mkfs.ext4 too?
There is a git tree. It's at:
http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=summary
The bleeding edge branch is the 'pu' (proposed updates), which you
need if you want the full ext4 features. Note that the userspace code
still needs a lot of work. It's for this reason that I haven't been
recommending people use it for production systems just yet.
In the next few weeks I will hopefully have more time to work on
e2fsprogs, so it should be much better by after the holidays.
- Ted
On Tue, November 20, 2007 04:11, Theodore Tso wrote:
> There is a git tree. It's at:
> http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=summary
>
> The bleeding edge branch is the 'pu' (proposed updates), which you
> need if you want the full ext4 features.
Ah, I've seen the git tree, but missed on the 'pu' branch. So it's
# git-checkout -b pu
to get the pu branch?
> Note that the userspace code still needs a lot of work.
> It's for this reason that I haven't been recommending people use it for
> production systems just yet.
Understood. But the more ppl testing your stuff the better, right?
Thanks for your time,
Christian.
--
BOFH excuse #442:
Trojan horse ran out of hay
On Tue, Nov 20, 2007 at 11:24:03AM +0100, Christian Kujau wrote:
> > Note that the userspace code still needs a lot of work.
> > It's for this reason that I haven't been recommending people use it for
> > production systems just yet.
>
> Understood. But the more ppl testing your stuff the better, right?
Oh, absolutely. I just don't think it's fair to encourage people to
use something that might cause them to risk their data unless they are
going into it with their eyes wide open. The 'pu' branch gets very
minimal testing. I do run the regression test suite(*), so it's a bit
more than "it builds, ship it!", but essentially almost any patch that
will apply gets thrown into 'pu', and as I review patches and fix up
issues, I move them to the 'next' branch, and then a little bit later
to the 'master' branch.
(*) With only 3-4 test failures, but at least some of them are tests
that need to be fixed up, not necessarily outright bugs in the 'pu'
branch.
At the moment in the git tree only the 'pu' branch has extents
support, and to be honest the support in e2fsprogs-interim in terms of
being able to better detect and fix corrupted filesystems without
crashing. (Some of the newer features like uninit groups and flexbg
isn't in e2fsprogs-interim, though.) Fixing up the extents support is
very high on my priority list over the next couple of weeks, but at
the moment e2fsck on the 'pu' branch will correctly check an ext4
filesystem with extents that isn't too badly corrupted; a badly
corrupted one will cause e2fsck to crash. It will get better, I
promise you! :-)
Regards,
- Ted
Theodore Tso wrote:
> On Tue, Nov 20, 2007 at 11:24:03AM +0100, Christian Kujau wrote:
>>> Note that the userspace code still needs a lot of work.
>>> It's for this reason that I haven't been recommending people use it for
>>> production systems just yet.
>> Understood. But the more ppl testing your stuff the better, right?
>
> Oh, absolutely. I just don't think it's fair to encourage people to
> use something that might cause them to risk their data unless they are
> going into it with their eyes wide open.
Please do report any problems you find, though. Ted has said that the
sourceforge bugtracker is the right place to do this for now.
-Eric (remembering he has a bug to report, too)
On Tue, Nov 20, 2007 at 08:56:41AM -0600, Eric Sandeen wrote:
> Theodore Tso wrote:
> > On Tue, Nov 20, 2007 at 11:24:03AM +0100, Christian Kujau wrote:
> >>> Note that the userspace code still needs a lot of work.
> >>> It's for this reason that I haven't been recommending people use it for
> >>> production systems just yet.
> >> Understood. But the more ppl testing your stuff the better, right?
> >
> > Oh, absolutely. I just don't think it's fair to encourage people to
> > use something that might cause them to risk their data unless they are
> > going into it with their eyes wide open.
>
> Please do report any problems you find, though. Ted has said that the
> sourceforge bugtracker is the right place to do this for now.
BTW, when reporting a bugs against the git tree, please include the
branch and the git ID (i.e., that which is reported by git-describe),
so there is no question which version you were running at the time.
The git ID won't be helpful if you have your own local commits against
the tree, but it can be useful if you are reporting a bug against the
"pu" branch and it has since been rewound as patches get rebased and
revised.
- Ted
On Tue, 20 Nov 2007, Theodore Tso wrote:
>> Please do report any problems you find, though. Ted has said that the
>> sourceforge bugtracker is the right place to do this for now.
>
> BTW, when reporting a bugs against the git tree, please include the
> branch and the git ID (i.e., that which is reported by git-describe),
> so there is no question which version you were running at the time.
Thanks for all the hints. But I don't intend to run e2fsprogs more than
needed (just the occasional tune2fs/e2fsck on an already created fs). As
soon as I have a testbox again, I can go crazy with these tools :)
Christian.
--
BOFH excuse #324:
Your packets were eaten by the terminator
Theodore Tso <[email protected]> writes:
> Oh, absolutely. I just don't think it's fair to encourage people to
> use something that might cause them to risk their data unless they
> are going into it with their eyes wide open. The 'pu' branch gets
> very minimal testing. I do run the regression test suite(*), so
> it's a bit more than "it builds, ship it!", but essentially almost
> any patch that will apply gets thrown into 'pu', and as I review
> patches and fix up issues, I move them to the 'next' branch, and
> then a little bit later to the 'master' branch.
>
> (*) With only 3-4 test failures, but at least some of them are tests
> that need to be fixed up, not necessarily outright bugs in the 'pu'
> branch.
>
> At the moment in the git tree only the 'pu' branch has extents
> support, and to be honest the support in e2fsprogs-interim in terms of
> being able to better detect and fix corrupted filesystems without
> crashing. (Some of the newer features like uninit groups and flexbg
> isn't in e2fsprogs-interim, though.) Fixing up the extents support is
> very high on my priority list over the next couple of weeks, but at
> the moment e2fsck on the 'pu' branch will correctly check an ext4
> filesystem with extents that isn't too badly corrupted; a badly
> corrupted one will cause e2fsck to crash. It will get better, I
> promise you! :-)
With the pu branch (98ec405d684b41be4ed8c3911dc7796bbacb8c68), I saw
lot of:
Error while reading over extent tree in inode 395164: Corrupt extent header
Clear inode<y>? yes
Error while reading over extent tree in inode 395165: Corrupt extent header
Clear inode<y>? yes
Error while reading over extent tree in inode 395166: Corrupt extent header
Clear inode<y>? yes
Error while reading over extent tree in inode 395167: Corrupt extent header
Clear inode<y>? yes
Error while reading over extent tree in inode 410957: Corrupt extent header
Clear inode<y>? yes
It's on a ext4 formated a week ago that sees lots of rsync tests.
And indeed, ls reporst some strange inodes:
(...)
-rw-r--r-- 1 tv 64876 2007-11-12 11:37 lang.pm
l????????? ? ? ? ? list_modules.pm
(...)
Would it be a kernel issue then?