| bugzilla-daemon |
| Apr 4, 8:00 am 2010 |
| bugzilla-daemon |
| Apr 4, 8:35 am 2010 |
| bugzilla-daemon |
| Apr 4, 8:31 am 2010 |
| bugzilla-daemon |
| Apr 4, 7:20 am 2010 |
| Theodore Tso | Re: [PATCH] ext4_freeze: don't return to userspace with ...
Yeah, it looks safe but it would be nice to do some testing to make sure there's nothing we missed.
I'm also vaguely worried whether the right thing will happen in no-journal mode, but it looks like it's better than what we had before (which clearly would have never worked in no journal mode), so I decided to let it pass.
Testing the freeze functionality definitely needs to be done before we trust what happens in no journal mode, for sure.
-- Ted
--
| Apr 4, 2:56 pm 2010 |
| Eric Sandeen | Re: [PATCH] ext4_freeze: don't return to userspace with ...
Well, there is __generic_file_aio_write doing vfs_check_frozen, but
I thought there was more at the vfs level to stop things from getting
to the filesystem... *shrug* I see you put the patch in as sent,
it sounds right to me.
Thanks,
-Eric
--
| Apr 4, 2:23 pm 2010 |
| tytso | Re: [PATCH] ext4_freeze: don't return to userspace with ...
Added to the ext4 patch queue, with the following patch comment:
ext4: don't return to userspace after freezing the fs with a mutex held
ext4_freeze() used jbd2_journal_lock_updates() which takes
the j_barrier mutex, and then returns to userspace. The
kernel does not like this:
================================================
[ BUG: lock held when returning to user space! ]
------------------------------------------------
lvcreate/1075 is leaving the kernel with locks still held!
1 ...
| Apr 4, 2:03 pm 2010 |
| tytso | Re: [PATCH] ext4_freeze: don't return to userspace with ...
Um, I think the addition of vfs_check_frozen(), esp. to
ext4_journal_start_sb() is absolutely necessary. What else do we have
to prevent filesystem modifications from going to the file systme
layer? I didn't see anything in the VFS layer that checks s_frozen;
am I missing something?
- Ted
--
| Apr 4, 1:52 pm 2010 |
| jing zhang |
| Apr 3, 6:26 pm 2010 |
| jing zhang |
| Apr 3, 11:26 pm 2010 |
| tytso | Re: [PATCH] ext4: add rb_tree cache to struct ext4_group_info
Maybe. I need to do more investigation to be sure. The code in
mballoc is subtle, and in some places there is stuff which is vestigal
or misnamed, but it means that I'm going to be very careful before
changing things.
It also means that if you submit patches, you need to be very clear
what you think the surrounding code is doing, why you think it's
wrong, and how your patch make things better. For example, this:
The function, ext4_mb_discard_group_preallocations(), works alone as
...
| Apr 3, 7:06 pm 2010 |
| tytso | Re: [PATCH] resize: check s_log_groups_per_flex before a ...
Yes, it does make sense to set flex_bg in this case; it allows the
group metadata to be stored outside of a blockgroup, which is helpful
to e2fsck in some cases when it needs to relocate an inode table and
there's no contiguous free space available in the block group.
- Ted
--
| Apr 3, 7:11 pm 2010 |
| tytso |
| Apr 3, 7:17 pm 2010 |
| tytso | Re: [PATCH 3/3] ext4: symlink must be handled via filesy ...
Added to the ext4 patch queue; I've added a Signed-off-by: for you
Dmitry, per your e-mail to Jan Kara.
(There seems to be some random confused people who think the
Signed-off-by has no legal significance, which is absolutely not true.)
- Ted
--
| Apr 4, 1:05 pm 2010 |
| jing zhang | Re: [PATCH] ext4: memory leakage in ext4_mb_init()
Sorry again, Ted.
There are so much for a newbie to learn to do cool work, especially to
meet your requirements. I am happy, any way, to patch ext4 under your
Without the cool git, though I am learning how to take advantage of
it, I could not manage all the patches delivered. In fact, I dig the
patches with UltraEdit for modifying the C code, Cygwin for git and
diff -Npu, and virtual machine for compiling. My kid, 11 years old
boy, has to share the HP notebook with me playing games.
And ...
| Apr 3, 6:05 pm 2010 |
| tytso | Re: [PATCH] ext4: memory leakage in ext4_mb_init()
How much testing are you doing before submitting patches, out of
Having independent patches is actually better --- but I think you're
misunderstanding what I was complaining about before. Patches should
that are accepted into mainline should do one and only one thing. So
if someone suggests that you make changes to your submitted patch,
ideally what you should do is to resubmit the patch with the fixes ---
and not submit a patch which is a delta to the previous one.
This is especially ...
| Apr 4, 11:08 am 2010 |
| tytso | Re: fsck more often when powerfail is detected (was Re: ...
Or migrate to ext4, which does use barriers by defaults, as well as
journal-level checksumming. :-)
As far as changing the default to enable barriers for ext3, you'll
need to talk to akpm about that; he's the one who has been against it
in the past.
- Ted
--
| Apr 4, 10:39 am 2010 |
| tytso | Re: fsck more often when powerfail is detected (was Re: ...
So what I recommend for server class machines is to either turn off
the automatic fsck's (it's the default, but it's documented and there
are supported ways of turning it off --- that's hardly developers
"ramming" it down user's throats), or more preferably, to use LVM, and
You can do this with ext3/ext4 today, now. Just take a look at
e2croncheck in the contrib directory of e2fsprogs. Changing it to not
Hmm, why are you running on battery so often? I make a point of
running connected to ...
| Apr 4, 12:29 pm 2010 |
| tytso | Re: fsck more often when powerfail is detected (was Re: ...
For people using e2croncheck, where you can check it when the system
is idle and without needing to do a power cycle, I'd recommend once a
Some distributions will allow you to cancel an fsck; either by using
^C, or hitting escape. That's a matter for the boot scripts, which
are distribution specific. Ubuntu has a way of doing this, for
example, if I recall correctly --- although since I've started using
e2croncheck, I've never had an issue with an e2fsck taking place on
bootup. Also, ext4, ...
| Apr 4, 12:35 pm 2010 |
