Bug#381982: truncate, XFS and starse files (Re: Bug#381982: Installation Report on AMD64 Laptop called deen)
On Thu, Aug 24, 2006 at 11:13:10PM +0200, Oleg Verych wrote: > Thank you very much ! > > I'm still wonder if all this 5Gi truncate() stuff matters to d-i > developers as bug... It may do, I'm not sure... it does seem quite odd behaviour, if it can be reproduced by them that'd help I guess. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381982: truncate, XFS and starse files (Re: Bug#381982: Installation Report on AMD64 Laptop called deen)
On 8/24/06, Nathan Scott <[EMAIL PROTECTED]> wrote: -- Nathan Thank you very much ! I'm still wonder if all this 5Gi truncate() stuff matters to d-i developers as bug... -- -o--=O`C #oo'L O <___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381982: truncate, XFS and starse files (Re: Bug#381982: Installation Report on AMD64 Laptop called deen)
On Wed, Aug 23, 2006 at 07:57:32AM +0200, Oleg Verych wrote: > I don't know POSIX, please answer the following. > File system file's block map may *not* be the same as actual data blocks > after truncate() ? If so, i'm going to check ls/dd size and du size of > all files. The block map does show the allocated data blocks, yes (there is a separate mapping for extended attributes, but set that aside as I don't think its relevent here). The size has no correlation to the block mapping, however. cheers. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381982: truncate, XFS and starse files (Re: Bug#381982: Installation Report on AMD64 Laptop called deen)
On 8/23/06, Nathan Scott <[EMAIL PROTECTED]> wrote: On Wed, Aug 23, 2006 at 06:39:31AM +0200, Oleg Verych wrote: > On 8/23/06, Nathan Scott <[EMAIL PROTECTED]> wrote: > So. What one must do ? I know XFS warrants _file system_ integrity > (not data), but > this is some kind of nasty thing 4K=5G. Hmm, no, this is some kind of POSIX thing. Most filesystems support sparse files, and truncation out beyond eof; am I misunderstading the problem here? I think problem is 5.2G /var/log/lastlog on fresh (only first logged user ever) installed OS. I really don't know what to add... I don't know POSIX, please answer the following. File system file's block map may *not* be the same as actual data blocks after truncate() ? If so, i'm going to check ls/dd size and du size of all files. I think this is wrong unless proved otherwise. so if you want it, you'll need to write a patch to xfsprogs packaging to do it (which I will happily accept, provided its tested and works). I'll try. Thanks. -- -o--=O`C #oo'L O <___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
