Ciaran McCreesh wrote:
> On Sun, 04 Oct 2009 21:53:11 +0200
> Rodolphe Rocca <[email protected]> wrote:
>>> or if you don't cleanly power off your computer after
>>> unmounting a filesystem, things will break.
>> but not this one.
>>
>> AFAIK when a fs is unmounted, a sync happens on the virtual device and
>> the unmount operation is blocking until all data has been flushed to
>> the disk (write cache). After what it's up to the hard drive firmware
>> to flush the write cache if it is enabled. So normally when unmount
>> returns, data is at least in the write cache of the drive. A power off
>> during the internal write cache flushing process will trigger data
>> loss. Not sure if the reboot will too.
> 
> Unmounting a filesystem doesn't force the disk to really really write
> its contents properly. In the general case, there's absolutely nothing
> a computer can do to force data to be really really written, whatever
> that even means.

That's actually what I said...

>> Concerning the merged files I agree that not much more can be done to
>> make paludis more resilient to a system crash.
>>
>> But what about /var/cache/db ?
> 
> Assuming you mean /var/db/pkg...

Right sorry.

> 
>> What I'm thinking about is letting paludis work as much as possible
>> in a temporary vdb directory and rename this directory in the safest
>> possible way once everything is done.
> 
> No point.
> 
>> Next time paludis runs, it could be able to detect inconsistencies and
>> automatically fix them. Something like :
> 
> A full VDB scan is slooooow, and might require permissions Paludis
> doesn't currently have. That's really not something we want to do.

Ok. The scan could be handled by an explicit option (--check-vdb).

>> Would it be insane ?
> 
> Yes, it would.
> 
> First, there is absolutely nothing whatsoever that userland software
> can do to deal with the user randomly powering off their computer.
> 
> Second, this is a huge amount of effort to avoid something that is
> entirely caused by a particularly unpleasant case of user error.

Not a user error, a system or hardware error.

Anyway I surrender, thanks a lot for your answers, I understand your
point of view.

_______________________________________________
paludis-user mailing list
[email protected]
http://lists.pioto.org/mailman/listinfo/paludis-user

Reply via email to