[ale] 1/3 full disk, but it is full?

[Joseph A. Knapka]

root wrote:
> 
> I thought a journaling fs, like Reiserfs, kept all the files in one big
> file, kind of like what the disk compression systems do (did?). Then
> they manipulate the files inside the big file. Or am I understanding
> this wrong?
> Ed.

Disclaimer: all I know about Reiserfs is that it was written
by a guy named Reiser (is that right?).

I think a journalling filesystem is just any filesystem that
keeps a record ("journal") of file modifications, so that
changes not committed to disk at crash time can be recovered.
Journal entries are always written to disk immediately, while
file contents may be buffered for a long while in RAM before
being committed to disk. Keeping the journal requires less
disk bandwidth than doing writes to actual files (journal
can be kept on contiguous disk blocks, no inode links to
follow around, etc.).

Aside from that, I don't think the term "journalling file system"
implies any particular implementation.

-- Joe

> "Joseph A. Knapka" wrote:
> >
> > Mel Burslan wrote:
> > >
> > > In the light of this message, one thing comes to mind: How fragmented
> > > your LARGE files are. Because, if my old knowledge of inodes and linked
> > > list structures are still serving me good, you are using one inode per
> > > fragment. And by my gut feeling, large, but really large files, are the
> > > files accessed and written over many many times by different
> > > users/processes, which can get badly fragmented. If this is the case,
> > > you may run out of inodes even with few large files. Just a thought, not
> > > even worth 2 cents ;-)
> > >
> >
> > You may be thinking of indirect blocks. In ext2 (I think), the inode
> > block contains a list of the disk blocks comprising the file. Those
> > blocks
> > can be anywhere on the disk; the order of the list in the inode
> > determines the logical order of blocks in the file. If there
> > are more blocks than can fit in an inode's list, some of the inode block
> > pointers point to disk blocks that contain not file data, but additional
> > lists of blocks in the file; the list block is an "indirect" block,
> > (or maybe the blocks it points to are called indirect blocks, I
> > can't remember). An indirect block is just another block, not an inode;
> > there really should be only one node per file or directory.
> >
> > Of course we're talking about Reiserfs here, so that's probably
> > completely irrelevant.
> >
> > -- Joe Knapka
> > "You know how many remote castles there are along the gorges? You
> >  can't MOVE for remote castles!" -- Lu Tze re. Uberwald
> > // Linux MM Documentation in progress:
> > // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
> > * Evolution is an "unproven theory" in the same sense that gravity is. *
> > --
> > To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.
> --
> To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.

-- 
"You know how many remote castles there are along the gorges? You
 can't MOVE for remote castles!" -- Lu Tze re. Uberwald
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. *
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.