Re: BigDisk project: du(1) 64bit clean.

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 01/05/05

  • Next message: Doug White: "Re: BigDisk project: du(1) 64bit clean." 
    Date: Tue, 04 Jan 2005 20:35:02 -0700 (MST)
To: julian@elischer.org

    In message: <41DB2B24.6050005@elischer.org>
                Julian Elischer <julian@elischer.org> writes:
    :
    :
    : Pawel Jakub Dawidek wrote:
    :
    : >Hi.
    : >
    : >I want you to look at two patches which makes du(1) 64bit clean.
    : >This work is part of the BigDisk project:
    : >
    : > http://www.freebsd.org/projects/bigdisk/
    : >
    : >
    : One thing that needs to be done is an 2ndary storage fsck.
    : that doesn't try put everything in RAM.
    : Basically this will mean extracting all the metadata from filesystems into
    : files and running sort operations of various kinds on them
    : to order the data in ways that allows consistencies to be checked.
    : It will take a bit longer than a RAM fsck but maybe not as much as
    : one might fear.
    : We all remember those "sort a mag-tape larger than RAM"
    : lessons from CS101 don't we?
    : At least it doesn't have to be "in place" so merge sorts are OK. :-)
    :
    : why?
    :
    : A bitmap of 1TB of 512 byte records is 244MB so with a 4BG machine
    : with 3GB available to the process you can't even fit the bitmaps into
    : memory for a 12TB Filesystem let alone other metadata.
    :
    : Going to 2048 byte frags helps but you still run into a limit.
    : last I tried it, you need about 600MB per TB of fileysstem to check.
    :
    : So I think a special fsck that uses files is a must for really big
    : filesystems, unless they (the filesystems) can be broken up in
    : a logical way (IBM did that many years ago I believe).
    : I think you should add that to your list.

    I think that a big amount of this could be reduced by using simple
    arrays rather than lists which are more memory efficient...

    Warner
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Doug White: "Re: BigDisk project: du(1) 64bit clean."

    Relevant Pages

    • Re: BigDisk project: du(1) 64bit clean.
      ... One thing that needs to be done is an 2ndary storage fsck. ... Basically this will mean extracting all the metadata from filesystems into ... It will take a bit longer than a RAM fsck but maybe not as much as ... We all remember those "sort a mag-tape larger than RAM" ...
      (freebsd-arch)
    • Re: [patch] stop inotify from sending random DELETE_SELF event under load
      ... >> lifetime rules of inodes in a way that might be OK for some filesystems, ... don't mess with inode refcount at all *and* make sure we don't ... go through that list instead of messing with inode lists? ... watches on a temporary list while holding dcache_lock and then hitting ...
      (Linux-Kernel)
    • Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
      ... a system today due to RAM constraints though I haven't really done any ... Most customers these days use 2-4 4-8TB filesystems per server ... We have many Lustre filesystems in the 100-200TB range today, ...
      (Linux-Kernel)
    • Re: Review/Test: Pseudo-device unit number management patch
      ... So far I haven't been able to plug-in the keyboard ... is mounted by filesystems or similar. ... And while it seems silly to not offer some sort of "oops" function ... GEOM offers some potential for solving this. ...
      (freebsd-current)
    • Re: Idea about a disc backed ram filesystem
      ... Currently we have ram filesystems and disc based file systems ... - mount the new fs over an existing dir as an overlay ... all reads are always done from the memory cache unless they are not cached ... But the current on.disk filesystems use caching of data in RAM extensively, ...
      (Linux-Kernel)