Re: Safe File Update (atomic)
* Ted Ts'o <tytso@mit.edu> schrieb:
> This is possible. It would be specific only to file systems that
> support inodes (i.e., ix-nay for NFS, FAT, etc.).
FAT supports inodes ?
IIRC it puts all file information (including attributes and first
data block) directly into the dirent ...
> Some file systems would want to know a likely directory where the
> file would be linked so for their inode and block allocation
> policies can optimize the inode and block placement.
Interesting. Do you know of some which do that and maybe some studies
on whether that's worth it ?
> A user might pass a file descriptor to another process in a different
> security domain, and that process could create a link to some
> directory which the original user doesn't have access to. The user
> would no longer be able to delete file and drop quota, and the process
> would retain permanent access to the file, which it might not
> otherwise have if the inode was protected by a parent directory's
> permissions.
Just curious: does the fd passing duplicate the fd or pass it as-is ?
(so multiple processes have access to the same fd instance instead
of just the same inode ?)
> 1) You care about data loss in the case of power failure, but not in
> the case of hard drive or storage failure, *AND* you are writing tons
> and tons of tiny 3-4 byte files and so you are worried about
> performance because you're doing something insane with large number of
> small files.
I'd be careful w/ declaring use of tons of small files insane.
Sure, this might call for a database, but hierachical filesystems
also might be a good interface for hierachical key-value-lists.
(for this, an read-at-once/write-at-once syscall would be nice ;-)).
> 3) You care about the temp file used by the userspace library, or
> application which is doing the write temp file, fsync(), rename()
> scheme, being automatically deleted in case of a system crash or a
> process getting sent an uncatchable signal and getting terminated.
Indeed, an automatic garbage collection for temp files would be nice.
But that also could be done by an new flag which tells the kernel
to automatically remove those files when the holding process terminates.
But this information would also have to be permanently recorded somewhere,
so the gc can still clean them up after hard reboot.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
Reply to: