Felix Miata wrote:
On EXT3 and EXT4, is journal space allocation a component of any of the df output? IOW, if space consumed is 98% and the journal is the default size, can or does the journal prevent consumption of that last 2%?
Reason for asking: I have a STB that according to blkid is using EXT3, a partition using the entirety of the "2TB" HD, for recordings. Even though there is far more freespace on the filesystem, 25991708 1K blocks (or more, subject to deleting test recording attempts), it's truncating recordings to about 13000K or 14000K, within a minute of beginning any recording. I'm trying to figure out how much space ultimately is or will be available before space is truly exhausted.
Can an EXT3 filesystem be "converted" to EXT2, IOW, dispense with the journal? How about changing the size of the journal to line up closely to the size of a typical recording file (somewhere in the 2G to 12G range).
Usually the journal is of a "fixed" size that doesn't change as you write files out. The journal is used to hold vital, but temporary information before the actual file has been written to disk and "sync'ed" (often, closed). That way if the disk crashes before your data is written to disk and the OS structures have recorded that fact, the journal can zero out any blocks that are allocated to you but never had that recorded in the journal (so you won't accidently get someone else's data in your file). Your numbers don't add up. You are saying the recordings are truncating @ ~13M, but the disk has about 25383M (or 24G) free. I.e. out of 2048G, you have 24G free when you start -- that would be slightly 1% of free space. Most OS's won't allow you allocate more than 90-95% -- you have less than 1.2% free which is *horrible*. For my busy disks, I try to always keep freespace >20-25%, but even on disks infrequently written to, I try not to go over 80-85% usage. Second bit about your numbers. Even though you have 24G free, you are saying your files stop recording at about 5-6% of that. If those numbers are real -- what rate are you recording? The problem is when you make the disks too full, it takes the OS longer and longer to find free space, which will usually be spread out all over the disk. Your application may even be at fault, maybe writing the recordings to a temporary file before writing them to the final destination. If your recording is consuming, say 5MB/s, the OS might not be able to keep up and end up returning "no space" before you've actually run out of space -- or it may be your application is unable to buffer enough space before the OS returns from a write call -- and your application aborts the recording when it realizes it "lost" part of the recording. OTOH, if you are recording slow stuff, like a 8kb/s (<1KB/s; Note: b=bits, B=Bytes) it may be writing the file to temp-space 1st to reduce destination fragmentation. Windows Explorer has done this since, at least, XP for file downloads -- 1st downloading to tmp space, then copies completed downloads to the final destination. Glancing at your datapoints, it looks like your disk is "too full" to perform well enough to record. I'd suggest recording to a disk that has >25% free space, and then, if you want, copying it to the over-filled disk -- that might work. But better would never to use over 90% (<75-80% would be better if you care about performance) of your disk space in a partition. When a normal 100+MB/s I/O disk gets to 99% full, it's write speed may really be down to 5MB/s or less. good luck -l -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org