On Mon, Jan 02, 2012 at 02:13:02PM +, Ben Hutchings wrote:
> Currently the value reported for max_batch_time is really the
> value of min_batch_time.
>
> Reported-by: Russell Coker
> Signed-off-by: Ben Hutchings
Applied, thanks.
- Ted
--
To UNSUB
> > My basic impression is that the use of "data=journalled" can help
> > reduce the risk (slightly) of serious corruption to some kinds of
> > databases when the application does not provide appropriate syncs
> > or journalling on its own (IE: such as text-based Wiki database files).
Yes, althoug
On Mon, Jun 27, 2011 at 05:30:11PM +0200, Lukas Czerner wrote:
> > I've found some. So although data=journal users are minority, there are
> > some. That being said I agree with you we should do something about it
> > - either state that we want to fully support data=journal - and then we
> > shoul
On Thu, Jun 23, 2011 at 01:32:48PM -0500, Moffett, Kyle D wrote:
>
> Ted, since this new iteration has no customer data, passwords, keys, or
> any other private data, I'm going to try to get approval to release an
> exact EC2 image of this system for you to test with, including the fake
> data vol
On Tue, Apr 05, 2011 at 10:30:11AM -0500, Moffett, Kyle D wrote:
> > Couple of questions which might give me some clues:
> > (a) was this a natively formatted ext4 file system, or a ext3 file
> > system which was later converted to ext4?
>
> All the filesystems were formatted like this usi
On Mon, Apr 04, 2011 at 09:24:28AM -0500, Moffett, Kyle D wrote:
>
> Unfortunately it was not a trivial process to install Debian
> "squeeze" onto an EC2 instance; it took a couple ugly Perl scripts,
> a patched Debian-Installer, and several manual
> post-install-but-before-reboot steps (like fixi
Hi Kyle,
Sorry for not following up sooner. Are you still able to reproduce
this failure? If I set up an identical Debian stable instance on
EC-2, am I likely to reproduce it myself? Do you have a package list
or EC2 base image I can use as a starting point?
Thanks,
On Mon, Nov 29, 2010 at 09:21:44AM -0600, Jonathan Nieder wrote:
>
> That explanation helps a lot. Thanks, both. (Guillem, I like your
> patch very much then. Most files being unpacked in a dpkg run aren't
> going to be read back again soon. Perhaps some other kernels will
> also interpret it
On Mon, Nov 29, 2010 at 02:58:16PM +, Ian Jackson wrote:
>
> This is the standard way that ordinary files for which reliability was
> important have been updated on Unix for decades. fsync is for files
> which need synchronisation with things external to the computer (or at
> least, external
On Mon, Nov 29, 2010 at 02:16:02PM +0100, Raphael Hertzog wrote:
>
> It means we don't need to keep it in RAM since we're not going to
> read/modifiy it again in the near future. Thus the writeback can be
> started right now since delaying it will not save us anything.
>
> At least that's the way
On Mon, Nov 29, 2010 at 02:46:11PM +0100, Raphael Hertzog wrote:
> On Mon, 29 Nov 2010, Theodore Tso wrote:
> > BTW, if you had opened the file handle in subsequent passes using
> > O_RDONLY|O_NOATIME, the use of fdatasync() instead of fsync() might not
> > have been necessary. And as far as the
I did some experimenting, and I figured out what was going on. You're
right, (c) doesn't quite work, because delayed allocation meant that
the writeout didn't take place until the fsync() for each file
happened. I didn't see this at first; my apologies.
However, this *does* work:
extract(a)
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote:
> Just to sum up what dpkg --unpack does in 1.15.8.6:
> 1/ set the package status as half-installed/reinst-required
> 2/ extract all the new files as *.dpkg-new
> 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by
>ren
13 matches
Mail list logo
