On Sun, Feb 24, 2008 at 04:32:40PM +, John Levon wrote:
> > There are plenty of things that can be done, including using search
> > paths to try to find vmlinuz; or maybe even proposing a new standard
> > such as say for example /lib/modules/`uname -r`/vmlinux being a
>
> At the time when I
On Sat, Feb 23, 2008 at 01:53:35PM +, John Levon wrote:
> On Sat, Feb 23, 2008 at 12:37:24PM +0100, Ingo Molnar wrote:
>
> > It's 200 lines of pretty well isolated code for something that is
> > already much more usable to me than 10 years of oprofile. Really, i'd
> > much rather take 200
On Sat, Feb 23, 2008 at 01:53:35PM +, John Levon wrote:
On Sat, Feb 23, 2008 at 12:37:24PM +0100, Ingo Molnar wrote:
It's 200 lines of pretty well isolated code for something that is
already much more usable to me than 10 years of oprofile. Really, i'd
much rather take 200 lines of
On Sun, Feb 24, 2008 at 04:32:40PM +, John Levon wrote:
There are plenty of things that can be done, including using search
paths to try to find vmlinuz; or maybe even proposing a new standard
such as say for example /lib/modules/`uname -r`/vmlinux being a
At the time when I was
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote:
> > A third option would be if people add new functions (with no users) in
> > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed
> > patch with users that will use those new features in various kernel
> > development
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote:
A third option would be if people add new functions (with no users) in
-rc2 or -rc3 timeframes as long as it is part of a fully reviewed
patch with users that will use those new features in various kernel
development trees.
...
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
> Two things may largely eliminate the need for parallel branches.
>
> 1. Do infrastructure changes and whole tree wide refactoring etc. in a
> compatible manner with a brief but nonzero transition period.
>
> 2. Insert a second
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
Two things may largely eliminate the need for parallel branches.
1. Do infrastructure changes and whole tree wide refactoring etc. in a
compatible manner with a brief but nonzero transition period.
2. Insert a second merge
On Mon, Feb 18, 2008 at 05:16:55PM +0100, Tomasz Chmielewski wrote:
> Theodore Tso schrieb:
>
>> I'd really need to know exactly what kind of operations you were
>> trying to do that were causing problems before I could say for sure.
>> Yes, you said you were removing unne
On Mon, Feb 18, 2008 at 04:57:25PM +0100, Andi Kleen wrote:
> > Use cp
> > or a tar pipeline to move the files.
>
> Are you sure cp handles hardlinks correctly? I know tar does,
> but I have my doubts about cp.
I *think* GNU cp does the right thing with --preserve=links. I'm not
100% sure,
On Mon, Feb 18, 2008 at 04:02:36PM +0100, Tomasz Chmielewski wrote:
> I tried to copy that filesystem once (when it was much smaller) with "rsync
> -a -H", but after 3 days, rsync was still building an index and didn't copy
> any file.
If you're going to copy the whole filesystem don't use
On Mon, Feb 18, 2008 at 02:31:40PM +0100, Ingo Molnar wrote:
> i guess this explains what static code metrics already suggest:
Am I right in assuming that code-quality is just a program which runs
checkpatch.pl and measures the number of warnings and calls them
errors?
On Mon, Feb 18, 2008 at 04:18:23PM +0100, Andi Kleen wrote:
> On Mon, Feb 18, 2008 at 09:16:41AM -0500, Theodore Tso wrote:
> > ext3 tries to keep inodes in the same block group as their containing
> > directory. If you have lots of hard links, obviously it can't really
> >
On Mon, Feb 18, 2008 at 03:03:44PM +0100, Andi Kleen wrote:
> Tomasz Chmielewski <[EMAIL PROTECTED]> writes:
> >
> > Is it normal to expect the write speed go down to only few dozens of
> > kilobytes/s? Is it because of that many seeks? Can it be somehow
> > optimized?
>
> I have similar
> So please deal with it like most other subsystem maintainers do and stop
> complaining about "code churn" - nobody but you changes the ext3
> codebase, it's one of the codebases least affected by general kernel
> flux, it's an ultimate "leaf" subsystem.
Right, sorry. I misread the filename;
On Mon, Feb 18, 2008 at 03:12:09PM +0200, Adrian Bunk wrote:
> If me resending this old patch collides with something finally getting a
> user this part of my patch shouldn't be applied now (but you might get
> it again in 6 months if it's still unused...).
>
> But generally such conflicts
On Mon, Feb 18, 2008 at 08:12:29AM +0100, Ingo Molnar wrote:
> > Nack. I don't object to un-exporting journal_update_superblock(),
> > because that is pretty internal, but the other functions are intended
> > specifically for use by code outside of JBD. For example, the journal
> > checksum
On Mon, Feb 18, 2008 at 08:12:29AM +0100, Ingo Molnar wrote:
Nack. I don't object to un-exporting journal_update_superblock(),
because that is pretty internal, but the other functions are intended
specifically for use by code outside of JBD. For example, the journal
checksum patch for
On Mon, Feb 18, 2008 at 03:12:09PM +0200, Adrian Bunk wrote:
If me resending this old patch collides with something finally getting a
user this part of my patch shouldn't be applied now (but you might get
it again in 6 months if it's still unused...).
But generally such conflicts would
On Mon, Feb 18, 2008 at 03:03:44PM +0100, Andi Kleen wrote:
Tomasz Chmielewski [EMAIL PROTECTED] writes:
Is it normal to expect the write speed go down to only few dozens of
kilobytes/s? Is it because of that many seeks? Can it be somehow
optimized?
I have similar problems on my linux
So please deal with it like most other subsystem maintainers do and stop
complaining about code churn - nobody but you changes the ext3
codebase, it's one of the codebases least affected by general kernel
flux, it's an ultimate leaf subsystem.
Right, sorry. I misread the filename; I
On Mon, Feb 18, 2008 at 04:18:23PM +0100, Andi Kleen wrote:
On Mon, Feb 18, 2008 at 09:16:41AM -0500, Theodore Tso wrote:
ext3 tries to keep inodes in the same block group as their containing
directory. If you have lots of hard links, obviously it can't really
do that, especially since we
On Mon, Feb 18, 2008 at 04:02:36PM +0100, Tomasz Chmielewski wrote:
I tried to copy that filesystem once (when it was much smaller) with rsync
-a -H, but after 3 days, rsync was still building an index and didn't copy
any file.
If you're going to copy the whole filesystem don't use rsync!
On Mon, Feb 18, 2008 at 02:31:40PM +0100, Ingo Molnar wrote:
i guess this explains what static code metrics already suggest:
Am I right in assuming that code-quality is just a program which runs
checkpatch.pl and measures the number of warnings and calls them
errors?
On Mon, Feb 18, 2008 at 04:57:25PM +0100, Andi Kleen wrote:
Use cp
or a tar pipeline to move the files.
Are you sure cp handles hardlinks correctly? I know tar does,
but I have my doubts about cp.
I *think* GNU cp does the right thing with --preserve=links. I'm not
100% sure, though ---
On Mon, Feb 18, 2008 at 05:16:55PM +0100, Tomasz Chmielewski wrote:
Theodore Tso schrieb:
I'd really need to know exactly what kind of operations you were
trying to do that were causing problems before I could say for sure.
Yes, you said you were removing unneeded files, but how were you
On Sun, Feb 17, 2008 at 06:55:06PM +0100, Julia Lawall wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
> side-effects to allow a definition of BUG_ON that drops the code completely.
Hi, in the future, please separate
On Sun, Feb 17, 2008 at 06:55:06PM +0100, Julia Lawall wrote:
From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
Hi, in the future, please separate ext4
On Fri, Feb 15, 2008 at 04:49:39PM -0800, Dave Hansen wrote:
> On Fri, 2008-02-15 at 19:32 -0500, Theodore Tso wrote:
> > On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote:
> > >
> > > This patch adds two function mnt_want_write() and mnt_drop_write().
>
On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote:
>
> This patch adds two function mnt_want_write() and mnt_drop_write().
> These are used like a lock pair around and fs operations that might
> cause a write to the filesystem.
Argh, is there some reason why this couldn't have gotten
On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote:
This patch adds two function mnt_want_write() and mnt_drop_write().
These are used like a lock pair around and fs operations that might
cause a write to the filesystem.
Argh, is there some reason why this couldn't have gotten
On Fri, Feb 15, 2008 at 04:49:39PM -0800, Dave Hansen wrote:
On Fri, 2008-02-15 at 19:32 -0500, Theodore Tso wrote:
On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote:
This patch adds two function mnt_want_write() and mnt_drop_write().
These are used like a lock pair around
On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote:
> I was amazed at how slow stgit was when I tried it out. I use
> git-quiltimport a lot and I don't think it's any slower than just using
> quilt on its own. So I think that the speed issue should be the same.
I like using "guilt" because
On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote:
I was amazed at how slow stgit was when I tried it out. I use
git-quiltimport a lot and I don't think it's any slower than just using
quilt on its own. So I think that the speed issue should be the same.
I like using guilt because I
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> On Tue, 12 Feb 2008, Greg KH wrote:
> >
> > Perhaps you need to switch to using quilt. This is the main reason why
> > I use it.
>
> Btw, on that note: if some quilt user can send an "annotated history file"
> of their quilt
On Tue, Feb 12, 2008 at 03:28:26PM -0800, David Miller wrote:
> From: Jan Engelhardt <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 15:00:20 +0100 (CET)
>
> > Something looks wrong here. Why would btrfs need to zero at all?
>
> So that existing superblocks on the partition won't
> be interpreted
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> On Tue, Feb 12, 2008 at 11:55:45AM -0800, Linus Torvalds wrote:
> > >
> > > Not it isn't. To quote you a number of years ago:
> > > "Linux is evolution, not intelligent design"
I think this statement has been used unfortunately as a
On Mon, Feb 11, 2008 at 11:06:17PM -0800, Arjan van de Ven wrote:
> There is maybe a middle ground in this -next idea; as very first
> part of the series, the new api gets added, current users converted
> and api marked __deprecated.
>
> Then there's a second part to the patch, which is a
On Mon, Feb 11, 2008 at 11:06:17PM -0800, Arjan van de Ven wrote:
There is maybe a middle ground in this -next idea; as very first
part of the series, the new api gets added, current users converted
and api marked __deprecated.
Then there's a second part to the patch, which is a separate
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
On Tue, Feb 12, 2008 at 11:55:45AM -0800, Linus Torvalds wrote:
Not it isn't. To quote you a number of years ago:
Linux is evolution, not intelligent design
I think this statement has been used unfortunately as a hard and fast
On Tue, Feb 12, 2008 at 03:28:26PM -0800, David Miller wrote:
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 15:00:20 +0100 (CET)
Something looks wrong here. Why would btrfs need to zero at all?
So that existing superblocks on the partition won't
be interpreted as correct
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
On Tue, 12 Feb 2008, Greg KH wrote:
Perhaps you need to switch to using quilt. This is the main reason why
I use it.
Btw, on that note: if some quilt user can send an annotated history file
of their quilt usage, it's
On Mon, Feb 11, 2008 at 11:45:55PM -0500, Trond Myklebust wrote:
> It would be very nice to have a separate tree with _only_ API changes
> that could be frozen well before Linus' merge window opens. It should be
> a requirement that maintainers use this tree as a basis for testing API
> changes
On Mon, Feb 11, 2008 at 11:45:55PM -0500, Trond Myklebust wrote:
It would be very nice to have a separate tree with _only_ API changes
that could be frozen well before Linus' merge window opens. It should be
a requirement that maintainers use this tree as a basis for testing API
changes and
On Wed, Feb 06, 2008 at 03:38:52AM -0800, David Schwartz wrote:
> >
> > Ndiswrapper loads and executes code with not GPLv2 compatible licences
> > in a way in the kernel that might be considered similar to a GPLv2'ed
> > userspace program dlopen() a dynamic library file with a not GPLv2
> >
On Wed, Feb 06, 2008 at 09:11:27AM +0100, Jiri Kosina wrote:
> On Tue, 5 Feb 2008, Theodore Tso wrote:
>
> I have also seen sound working flawlessly on another X61s. Maybe they
> changed some chipset revisions on the fly, or whatever.
>
> What does lspci -v show for you
On Wed, Feb 06, 2008 at 09:11:27AM +0100, Jiri Kosina wrote:
On Tue, 5 Feb 2008, Theodore Tso wrote:
I have also seen sound working flawlessly on another X61s. Maybe they
changed some chipset revisions on the fly, or whatever.
What does lspci -v show for your soundcard please?
Attached
On Wed, Feb 06, 2008 at 03:38:52AM -0800, David Schwartz wrote:
Ndiswrapper loads and executes code with not GPLv2 compatible licences
in a way in the kernel that might be considered similar to a GPLv2'ed
userspace program dlopen() a dynamic library file with a not GPLv2
compatible
On Tue, Feb 05, 2008 at 10:16:08PM +0100, Jiri Kosina wrote:
> [ added Takashi ]
>
> On Tue, 5 Feb 2008, Felipe Balbi wrote:
>
> > > > > > Could anyone make T61P's ICH8 sound controller to work properly?
> > Good that there's a lot of people using T61p, it's a good machine.
> > I'll upgrade my
On Tue, Feb 05, 2008 at 10:16:08PM +0100, Jiri Kosina wrote:
[ added Takashi ]
On Tue, 5 Feb 2008, Felipe Balbi wrote:
Could anyone make T61P's ICH8 sound controller to work properly?
Good that there's a lot of people using T61p, it's a good machine.
I'll upgrade my BIOS and try
On Sat, Feb 02, 2008 at 10:55:24AM -0500, Theodore Ts'o wrote:
> In the mm tree is a patch queued up to nuke iget(). So replace use of
> iget() with iget_locked(). I will be pushing this to Linus shortly.
Oops, wrong version of the patch; this is the correct one.
On Sat, Feb 02, 2008 at 10:55:24AM -0500, Theodore Ts'o wrote:
In the mm tree is a patch queued up to nuke iget(). So replace use of
iget() with iget_locked(). I will be pushing this to Linus shortly.
Oops, wrong version of the patch; this is the correct one.
On Tue, Jan 29, 2008 at 10:54:03PM +0100, Jan Engelhardt wrote:
>
> On Jan 29 2008 07:53, Theodore Tso wrote:
> >
> >>fwiw, diffstat is confused by git's diff output; you need to use
> >>'diffstat -p1'
>
> I am seeing normal behavior:
>
> 22:52 so
>fwiw, diffstat is confused by git's diff output; you need to use
>'diffstat -p1'
Argh, I have *got* to create a script that does this automatically.
Revised diffstat -p1 output follows...
- Ted
Documentation/filesystems/ext4.txt |
fwiw, diffstat is confused by git's diff output; you need to use
'diffstat -p1'
Argh, I have *got* to create a script that does this automatically.
Revised diffstat -p1 output follows...
- Ted
Documentation/filesystems/ext4.txt | 20
On Tue, Jan 29, 2008 at 10:54:03PM +0100, Jan Engelhardt wrote:
On Jan 29 2008 07:53, Theodore Tso wrote:
fwiw, diffstat is confused by git's diff output; you need to use
'diffstat -p1'
I am seeing normal behavior:
22:52 sovereign:~/linux git diff HEAD | diffstat
That's because you
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
>
> As user pages are always in highmem, this should be easy to decide:
> only send SIGDANGER when highmem is full. (Yes, there are
> inodes/dentries/file descriptors in lowmem, but I doubt apps will
> respond to SIGDANGER by closing
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
As user pages are always in highmem, this should be easy to decide:
only send SIGDANGER when highmem is full. (Yes, there are
inodes/dentries/file descriptors in lowmem, but I doubt apps will
respond to SIGDANGER by closing
On Wed, Jan 23, 2008 at 02:06:54PM -0800, Andrew Morton wrote:
> brelse() should only be used when the bh might be NULL - put_bh()
> can be used here.
>
> Please review all ext4/jbd2 code for this trivial speedup.
I've reviewed all of the pending patches in the stable queue for this
speedup, and
On Fri, Jan 25, 2008 at 05:55:51PM -0800, Bryan Henderson wrote:
> I was surprised to see AIX do late allocation by default, because IBM's
> traditional style is bulletproof systems. A system where a process can be
> killed at unpredictable times because of resource demands of unrelated
>
On Fri, Jan 25, 2008 at 05:55:51PM -0800, Bryan Henderson wrote:
I was surprised to see AIX do late allocation by default, because IBM's
traditional style is bulletproof systems. A system where a process can be
killed at unpredictable times because of resource demands of unrelated
On Thu, Jan 24, 2008 at 11:25:32AM +0530, Aneesh Kumar K.V wrote:
> +static int free_ext_idx(handle_t *handle, struct inode *inode,
> + struct ext4_extent_idx *ix)
> +{
> + int i, retval = 0;
> + ext4_fsblk_t block;
> + struct buffer_head *bh;
> +
On Fri, Jan 25, 2008 at 10:34:25AM -0600, Eric Sandeen wrote:
> > But it was this concern which is why ext3 never exported freeze
> > functionality to userspace, even though other commercial filesystems
> > do support this. It wasn't that it wasn't considered, but the concern
> > about whether or
On Fri, Jan 25, 2008 at 03:18:51PM +0300, Dmitri Monakhov wrote:
> First of all Linux already have at least one open-source(dm-snap),
> and several commercial snapshot solutions.
Yes, but it requires that the filesystem be stored under LVM. Unlike
what EVMS v1 allowed us to do, we can't
On Thu, Jan 24, 2008 at 11:25:32AM +0530, Aneesh Kumar K.V wrote:
+static int free_ext_idx(handle_t *handle, struct inode *inode,
+ struct ext4_extent_idx *ix)
+{
+ int i, retval = 0;
+ ext4_fsblk_t block;
+ struct buffer_head *bh;
+
On Fri, Jan 25, 2008 at 10:34:25AM -0600, Eric Sandeen wrote:
But it was this concern which is why ext3 never exported freeze
functionality to userspace, even though other commercial filesystems
do support this. It wasn't that it wasn't considered, but the concern
about whether or not it
On Fri, Jan 25, 2008 at 03:18:51PM +0300, Dmitri Monakhov wrote:
First of all Linux already have at least one open-source(dm-snap),
and several commercial snapshot solutions.
Yes, but it requires that the filesystem be stored under LVM. Unlike
what EVMS v1 allowed us to do, we can't currently
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> In practice, there is a small number of programs that are both the
> common memory hogs and should be able to reduce their memory consumption
> by 10% or 20% without big problems when requested (e.g. Java VMs,
> Firefox and databases
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
In practice, there is a small number of programs that are both the
common memory hogs and should be able to reduce their memory consumption
by 10% or 20% without big problems when requested (e.g. Java VMs,
Firefox and databases come
On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
> > AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
> > the system was about to hit OOM, not when it was about to start swapping.
>
> I'd tried to advocate SIGDANGER some years ago as well, but none of
> the
On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
the system was about to hit OOM, not when it was about to start swapping.
I'd tried to advocate SIGDANGER some years ago as well, but none of
the kernel
On Sat, Jan 19, 2008 at 08:10:20PM -0800, Daniel Phillips wrote:
>
> I can see value in preemptively loading indirect blocks into the buffer
> cache, but is building a second-order extent tree really worth the
> effort? Probing the buffer cache is very fast.
It's not that much effort, and for
On Sat, Jan 19, 2008 at 08:10:20PM -0800, Daniel Phillips wrote:
I can see value in preemptively loading indirect blocks into the buffer
cache, but is building a second-order extent tree really worth the
effort? Probing the buffer cache is very fast.
It's not that much effort, and for a
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
> But I heard some years ago from a disk drive engineer that that is a myth
> just like the rotational energy thing. I added that to the discussion,
> but admitted that I haven't actually seen a disk drive write a partial
>
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a myth
just like the rotational energy thing. I added that to the discussion,
but admitted that I haven't actually seen a disk drive write a partial
sector.
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
>
> Have you observed that in the wild? A former engineer of a disk drive
> company suggests to me that the capacitors on the board provide enough
> power to complete the last sector, even to park the head.
>
The problem isn't
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
Have you observed that in the wild? A former engineer of a disk drive
company suggests to me that the capacitors on the board provide enough
power to complete the last sector, even to park the head.
The problem isn't with
On Tue, Jan 15, 2008 at 01:15:33PM +, Christoph Hellwig wrote:
> They won't fsck in planned downtimes. They will have to use fsck when
> the shit hits the fan and they need to. Not sure about ext3, but big
> XFS user with a close tie to the US goverment were concerned about this
> case for
On Tue, Jan 15, 2008 at 01:15:33PM +, Christoph Hellwig wrote:
They won't fsck in planned downtimes. They will have to use fsck when
the shit hits the fan and they need to. Not sure about ext3, but big
XFS user with a close tie to the US goverment were concerned about this
case for
On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote:
> On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
> > Also, I must say that e2fsck is brain-damaged, if it can be confused
> > by/do the stupid then when the system clock has warped by just a few
> > hours, not the _days_ that a
On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote:
On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
Also, I must say that e2fsck is brain-damaged, if it can be confused
by/do the stupid then when the system clock has warped by just a few
hours, not the _days_ that a file
On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote:
> On 2008-01-10 08:16 -0500, Theodore Tso wrote:
> > > It displays just the right time. On boot anyway. (Linux has had some
> > > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
> >
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
>
> Ok, but let's look at this a bit more opportunistic / optimistic.
>
> Even after a black-out shutdown, the corruption is pretty minimal, using
> ext3fs at least.
>
After a unclean shutdown, assuming you have decent hardware that
On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote:
On 2008-01-10 08:16 -0500, Theodore Tso wrote:
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
advanding even 15 minutes a day
On Fri, Jan 11, 2008 at 11:41:40AM -0800, Linus Torvalds wrote:
>
> (I also wonder if we should limit the number of entries we print out.
> Sometimes the stack frame ends up being so deep that we lose the
> *important* stuff. I think it might be good idea to have some rule like
> "the first 5
On Fri, Jan 11, 2008 at 11:41:40AM -0800, Linus Torvalds wrote:
(I also wonder if we should limit the number of entries we print out.
Sometimes the stack frame ends up being so deep that we lose the
*important* stuff. I think it might be good idea to have some rule like
the first 5
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote:
> On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> wrote:
> > fix your hardware clock then
>
> It displays just the right time. On boot anyway. (Linux has had some
> serious problems keeping the time after the switch from 2.6.7 to
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote:
On 2008-01-09, Mathieu SEGAUD [EMAIL PROTECTED] wrote:
fix your hardware clock then
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote:
>
> Does this create a snapshot of the *disk* at that moment, or does it
> capture "disk plus still-to-be-written blocks in the cache"?
> (Phrased differently, does it Do The Right Thing regarding "blocks
> queued before lvcreate"
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote:
> On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
> > On 09.01.2008 09:56, Tuomo Valkonen wrote:
> > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > > > That what LABEL und UUID-Support in mount is for.
>
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > That will fix the this issue. The problem you are facing is that you
> > have your hardware clock set to ticking localtime, instead of G
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
On Jan 8, 2008 7:15 PM, Theodore Tso [EMAIL PROTECTED] wrote:
That will fix the this issue. The problem you are facing is that you
have your hardware clock set to ticking localtime, instead of GMT.
Windows ticks localtime
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote:
On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
On 09.01.2008 09:56, Tuomo Valkonen wrote:
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
That what LABEL und UUID-Support in mount is for.
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote:
Does this create a snapshot of the *disk* at that moment, or does it
capture disk plus still-to-be-written blocks in the cache?
(Phrased differently, does it Do The Right Thing regarding blocks
queued before lvcreate and
On Tue, Jan 08, 2008 at 09:51:53PM +0100, Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
> >
> > Now, there are good reasons for doing periodic checks every N mounts
> > and after M months. And it has to do with PC class hardware. (Ted's
> > aph
On Tue, Jan 08, 2008 at 12:19:44PM -0800, Daniel Walker wrote:
> > But is discourage the creation of pure clean-up patches because it
> > may have a disturbing effect on several other peoples work.
>
> pure clean ups are _good_ patches , are they not?
>
Not necessarily. Whether or not it is
On Tue, Jan 08, 2008 at 10:01:19AM -0800, Daniel Walker wrote:
> > It is a simple pain/benefit issue.
> > Fixing the 25 errors and 13 warnings in kernel/profile.c may look
> > like an easy task but then we put additional burden on the 10 people
> > that have patches pending for this file.
>
>
On Tue, Jan 08, 2008 at 05:01:30PM +, Tuomo Valkonen wrote:
> On 2008-01-08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > tune2fs -i0 -c0 device for each file system
> >
> > Yes that should be default, unfortunately it is not. It's one
> > of the first things I do on new machines.
>
> I
On Tue, Jan 08, 2008 at 10:01:19AM -0800, Daniel Walker wrote:
It is a simple pain/benefit issue.
Fixing the 25 errors and 13 warnings in kernel/profile.c may look
like an easy task but then we put additional burden on the 10 people
that have patches pending for this file.
This goes for
On Tue, Jan 08, 2008 at 05:01:30PM +, Tuomo Valkonen wrote:
On 2008-01-08, Andi Kleen [EMAIL PROTECTED] wrote:
tune2fs -i0 -c0 device for each file system
Yes that should be default, unfortunately it is not. It's one
of the first things I do on new machines.
I have ages ago
1 - 100 of 724 matches
Mail list logo
