Re: [Nix-dev] The fsync issues with nix
On 03/21/2012 03:11 PM, Lluís Batlle i Rossell wrote: So, user tools have to be written properly, so they fsync data before 'mv'. From Nix's standpoint, isn't the real requirement 'fsync before updating the database'? Is there some way for Nix to say Make sure every file in this directory is actually written to disk before updating sqlite? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The fsync issues with nix
You're asking to do fsync before registering store paths valid, correct? If its not done yet it makes much sense to me. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The fsync issues with nix
On Wed, Mar 21, 2012 at 08:21:46PM +0100, Marc Weber wrote: You're asking to do fsync before registering store paths valid, correct? If its not done yet it makes much sense to me. Well, I think there are only two available operations: fsync(int fd) and sync(). One is much faster and less intrusive than the other. But what to do, when it isn't nix that writes the files, and thus, nix has not the handles open? Maybe sync() is the quick solution? Or should nix open all files and fsync them? Regards, Lluís. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The fsync issues with nix
Excerpts from Lluís Batlle i Rossell's message of Wed Mar 21 20:39:20 +0100 2012: Well, I think there are only two available operations: fsync(int fd) and sync(). One is much faster and less intrusive than the other. But what to do, when it isn't nix that writes the files, and thus, nix has not the handles open? Maybe sync() is the quick solution? Or should nix open all files and fsync them? Thinking about it again I feel we don't want broken stores ever. Thus at the very least the hashes nix-store --verify --check-contents uses must be synced. Are they contained in sqlite? Then there should be no (big) problem. Then you ended up with a broken store - but you were still able to run an older revision, right? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The fsync issues with nix
On Wed, Mar 21, 2012 at 08:58:43PM +0100, Lluís Batlle i Rossell wrote: On Wed, Mar 21, 2012 at 08:39:20PM +0100, Lluís Batlle i Rossell wrote: On Wed, Mar 21, 2012 at 08:21:46PM +0100, Marc Weber wrote: You're asking to do fsync before registering store paths valid, correct? If its not done yet it makes much sense to me. Well, I think there are only two available operations: fsync(int fd) and sync(). One is much faster and less intrusive than the other. But what to do, when it isn't nix that writes the files, and thus, nix has not the handles open? Maybe sync() is the quick solution? Or should nix open all files and fsync them? Just as an additional note, and as 'cwillu' pointed at #btrfs, 'mv' is an atomic operation for file entries, but not about the file contents. Only succesful fsync/sync will ensure the changes go to the hardcopy of the fs. Additionally, I don't know if fsync() can be used effectively on a file already written and closed, by reopening it again. By the manpage I understand that it's possible to do that. But then I don't know why I can't find any user tool that fsyncs files. G in another computer where I put 'xfs', I'm getting zero-length files too. I'm on X, run nixos-rebuild switch --fast, and during the profile switch it crashes, and the video screen goes mad. Quite bad... ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
