[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: sparse loop devices and ext3

On Thu, 8 Feb 2001, Stephen C. Tweedie wrote:

> Hi,
> On Tue, Feb 06, 2001 at 04:50:01PM -0800, Peter J. Braam wrote:
> > 
> > The problem I saw was that the allocation of blocks was not handled
> > all that well and seriously rolled back during recovery.
> Loop doesn't allocate blocks as far as I know.  At least, not on files
> using bmap.  bmap() is a read-only API.

It has a function create_missing_block, that calls f_write. So it should
allocate within an ext3 transaction.  So where is all this corruption
coming from: probably the fix to 5e you sent in a few days ago.

- Peter -

> > So shouldn't bmap in ext3 start a transaction to eliminate that?
> No, because bmap() never allocates anything.  Ever.
> One thing on the todo list for bmap() is to make it force any
> data-journaled updates which are still in the log to be migrated back
> to their main home location on disk before returning.  That would be
> needed to make "lilo; sync; reboot -f" safe on data-journaled
> partitions (the sync only forces the data to the journal, not
> necessarily to the primary disk blocks).  But that's not an issue for
> loop devices, as far as I can see.
> The loop device _does_ check for sparse files: if it finds a zero
> return on bmap(), it then calls the filesystem's write function to
> allocate that block of the file.  In the ext3 case, that *will* be
> journaled.
> Cheers,
>  Stephen
> _______________________________________________
> Ext3-users mailing list
> Ext3-users redhat com
> https://listman.redhat.com/mailman/listinfo/ext3-users


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]