[mythtv-users] ext3 suitability (Was: Re: Block size for ext3 partition)

[Keith Pyle]

>> On Jan 20, 2008, at 7:46 AM, Kevin Kuphal wrote:
>>
>>     
>>> On Jan 20, 2008 8:06 AM, William Munson <w.munson at comcast.net> wrote:
>>> Phill Edwards wrote:
>>>       
>>>> In order to make it easier to install CentOS I am going to
>>>>         
>>> reformat my
>>>       
>>>> JFS file system which stores my recordings to EXT3. It's a 320GB IDE
>>>> disk. The archives have lots of file system discussions but I can't
>>>> find anything which says what block size to format the EXT3
>>>>         
>>> partition
>>>       
>>>> with for storing large files like recordings. Can anybody advise?
>>>>         
>>> Just a note, I've been using JFS for a *long* time without issues.
>>>       
>
> I will second this.
>
> EXT3 was painful. Running JFS has been much better for my recordings drive.
>   
I've read the comments about ext3 vs. other filesystems with interest 
for some time.  I've seen a number of comments such as the one above 
suggesting difficulties with ext3.  I've had no such issues.  My 
mythbackend has two 250 GB SATA 2 drives connected to separate channels 
on an Intel D945 motherboard that has 1 GB memory.  Each drive has the 
first ~1200 cylinders partitioned to support the typical OS filesystems 
(each major filesystem in its own partition, of course) and swap.  The 
remaining ~29K cylinders on each drive are considered physical volumes 
in a LVM volume group.  The volume group uses a 64 MB extent size and 
contains one logical volume that is configured striped, with a 128 KB 
stripe size (i.e., lvcreate -i 2 -I 128 -r 32...)  The logical volume 
contains an ext3 filesystem created with the following mkfs options:

-b 4096 -O sparse_super -m 0 -T largefile4

to yield a ~440 GB filesystem for myth use.  The large VG extent size 
would allow a volume group of up to 4 TB, and the stripe configuration 
causes LVM to alternate writes between the two disks (this is very 
apparent on I/O monitors).  While largefile4 does reduce the number of 
files that can exist, the 110K inodes in this filesystem are far more 
than enough for video use, with typically a percent or two used with the 
disk nearly full.  The video filesystem is mounted with the noatime and 
commit=30 options.  These options eliminate unnecessary access time 
updates to the filesystem (that would be almost constant otherwise) and 
increase the time between sync operations.  I recognize that LVM does 
not provide the protection of RAID-5, but I do not feel the need for 
RAID protection with the backend.

The reason for both disks having the first section for OS is that this 
allows the parallel installation of two different OS versions, making 
for fairly easy upgrades and back-out if needed.  At any time though, 
the active OS and the mysql database reside only one disk.

The backend has two PVR-500's, and I've proven that I can record four SD 
shows concurrently while watching a fifth (previously recorded) program 
using a MediaMVP accessing the backend video partition via NFS.  This is 
with no drops, stutters, etc. in any of the recordings in spite of the 
considerable I/O.  I also delete while recordings are in progress with 
no problems.  I do not have slow deletes enabled.  I see no issues with 
mysql updating the seek table.

My point is that while the choice of filesystem can be a factor, there 
are many other aspects to performance and ext3 is not by itself a bad 
choice in a well designed system.