[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg should support a --force-unsafe-io option or such


On sekmadienis 10 Spalis 2010 01:06:41 Otavio Salvador wrote:
> On Fri, Oct 8, 2010 at 8:55 PM, Modestas Vainius <modax@debian.org> wrote:
> ...
> > It does not make much sense for dpkg to be in this uber-paranoid mode at
> > debian-installer time. If power fails, install process will probably have
> > to be started from scratch anyway. What's more, obviously I have no
> > choice to use libeatmydata or similar to fight this dpkg behaviour at
> > debian installer time.
> > 
> > In my opinion, dpkg should provide a way to turn off those offensive
> > *sync() calls and debian installer should make use of it.
> I fully agree that d-i doesn't need and shouldn't use it by default.
> In fact some embedded systems shouldn't use it either in production
> mode if the media suffer of wearing.
> As previously said in this thread, d-i needs to be restarted in case
> of power outage or something broken and fsync won't help on that
> except make it taking longer.

I feel rather strong about this issue because I keep running and running into 
it in different situations. I truly believe that it should be high priority 
for squeeze but I won't bump severity myself. To sum up:

1) current dpkg is bog slow on modern file systems (brtfs, ext4). What is 
more, due to frequent sync() calls, it is a very bad idea to run dpkg when 
other unrelated disk I/O (esp. on modern FSes) is in the background. It just 
slows everything down.

2) current dpkg is arguably not suitable for flash media (i.e. embedded 
devices). This hurts the "universal" part of Debian OS.

3) dpkg is pointlessly slow in such use cases as buildds where *sync() is not 
important at all.

4) while typical dpkg could be work arounded with libeatmydata, there is no 
cure for debian-installer.

And all this is to protect against power failure? Sure, the purpose is noble 
and maybe it's a good default but due to negative side effects I find it 
unacceptable that this behaviour is not configurable.

Modestas Vainius <modax@debian.org>

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: