[mythtv-users] LVM Issue with zero-length files

[Shawn Asmussen]

On 9/28/05, Larry K <lunchtimelarry at gmail.com> wrote:
>
> Calling all LVM experts!!
>
> Up until recently, I had been running LVM with only a single physical
> volume. I probably have 100GB of data files in the volume, waiting to be
> watched. So, Myth was running fine and all was well, except I had a 150GB
> partition just laying around, not in use. So, I decided to extend my volume
> group and add this 150GB to it, like so:
>
>    1. Using fdisk, deleted /dev/hda4 partition
>    2. Using fdisk, created /dev/hda4 as LVM
>    3. Created physical volume: pvcreate /dev/hda4
>    4. Extended volume group: vgextend vg /dev/hda4
>    5. Ran vgdisplay to see amount of free space that needs to be
>    extended (18214)
>    6. unmount the volume group: umount /dev/vg/video
>    7. extend: lvextend -l +18214 /dev/vg/video
>    8. mount /dev/vg/video
>    9. grow the xfs file system: xfs_grow /dev/vg/video
>    10. Remove /video from /etc/fstab
>
> Now, df -k shows the new space:
>
> [root at mythtv ~]# df -k
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/hda2 10080520 2938120 6630332 31% /
> /dev/hda1 101086 16752 79115 18% /boot
> none 257908 0 257908 0% /dev/shm
> /dev/mapper/vg-video 442105856 113816336 328289520 26% /video2
>
> Everything appeared to be OK. I now had a 450GB partition for myth,
> instead of 300GB. However, I soon discovered that new files are written with
> a length of zero (empty files). Doh! The mythfrontend was able to play back
> the existing files that were in the VG, but if I tried to delete a file, the
> frontend would hang. That's when I knew I had a problem for sure.
>
> Also odd is that when, as root, I cat /dev/video0 > /video2/xxx.mpg, this
> file is also empty. However, if I copy an existing file, as in
>
> cp /video2/blah blah.nuv /video2/xxx, it shows up with the proper length.
> So old files copy correctly, but new files are not written correctly.

 The fact that you can write files this way, tends to suggest that it might
not be a problem with your xfs filesystem. Could your ivtv drivers (Or
whatever you're using) have gotten confused during this procedure somehow,
and stopped producing output? I would try to do a cat /dev/video test, but
write the test file somewhere else that isn't on your expanded filesystem.
If you get a zero length file there, I would suggest rebooting your box, and
making sure that your capture drivers are working. If they got hosed up
somehow, it could explain both why your cat /dev/video0 test, and why new
files created created by mythtv were zero length. BTW, I didn't notice it in
your list of steps, so did you shutdown mythbackend during this procedure?
You say that you can copy existing files, but not write new ones, but you
didn't mention trying to write new files by any other method than the cat
/dev/video0 method. Did you try anything else, like creating a new file with
vi, or something like that? If that works, and your cat /dev/video0 doesn't
work, I'd almost certainly say that something is going on with the video
capturing itself, not your xfs filesystem.

WTF?
>
> There are no error messages in either the myth logs, nor the log file at
> /var/log/messages.
>
> I did notice that one of the HDs is running DMA 100, while the other is
> DMA 133. Does this matter to LVM?

 Shouldn't make any difference.

Anyone have any thoughts as to what might be causing this? I am totally
> stumped. If there is a way to back out and shrink the VG back to 300GB to
> fix this, I'm all ears!
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20050928/80d363b8/attachment.htm