[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    RE: Migrating HFS: fake inode i_size?
From:       Luka Renko <luka.renko () hermes ! si>
Date:       2001-02-19 13:39:31
[Download RAW message or body]

You could just create sparse file instead. You just truncate the file,
lseek() to original size and write a single byte.

Regards,
Luka

> -----Original Message-----
> From: Malcolm Beattie [mailto:mbeattie@sable.ox.ac.uk]
> Sent: Monday, 19. February 2001 13:26
> To: linux-fsdevel@vger.kernel.org
> Subject: Migrating HFS: fake inode i_size?
> 
> 
> Background:
> 
> I'm probably going to reimplement the "migrating hierarchical
> filesystem" (fancy name, simple idea) that I did a proof of concept
> for with Linux 1.0/1.2 (or 0.99/1.0, I forget). Migrating a file
> off the system (ext2 for now) is done by userland copying the file
> elsewhere and then, on the kernel side, an ioctl which truncates
> the file's data blocks, sets a "migrated" attribute in the (on-disk)
> inode but leaves i_size at the original size. When a process tries
> to open a file with the "migrated" attribute, it blocks and a
> migration daemon waiting in an ioctl() (or whatever) is woken up
> and passed an open file descriptor on the underlying file. The
> migration daemon gets the file data back however it likes and writes
> the data to the underlying file. When finished, it does an ioctl()
> which resets the migrated attribute and wakes any processes blocked
> in open().
> 
> Question:
> 
> How safe is it to have a faked i_size in an inode? The only process
> to get an actual open descriptor on such an inode will be the
> migration daemon (which will be privileged, of course) but it would
> be nice to know how horribly things could break if it did things
> other than write() data to the underlying file. (The reason for
> leaving the original i_size in place is so that programs just doing
> stat() on it see the right (meta)data so that the migration is
> fairly transparent, apart from lsattr etc.)
> 
> --Malcolm
> 
> -- 
> Malcolm Beattie <mbeattie@sable.ox.ac.uk>
> Unix Systems Programmer
> Oxford University Computing Services
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org

[prev in list] [next in list] [prev in thread] [next in thread]