Shawn,<br>
<br>
You were right on the money. <br>
<br>
Somehow, my ivtv driver must have gotten messed up when I installed the
new xfs volume. I can't figure that one out, tho. I
was so focused on the xfs/LVM issue, it never occurred to me that the
ivtv drivers got hosed. Good call.<br>
<br>
I ran a few more tests and found that I could create new files with vi,
and cat /dev/video did not work no matter where I directed the
output. <br>
<br>
Anyhow, after I reinstalled ivtv, the problem went away. <br>
<br>
Thanks for the help. Your questions made me think outside the box I was stuck in :)<br><br><div><span class="gmail_quote">On 9/28/05, <b class="gmail_sendername">Shawn Asmussen</b> <<a href="mailto:shawn.asmussen@gmail.com">
shawn.asmussen@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>
<div><span class="q"><span class="gmail_quote">On 9/28/05, <b class="gmail_sendername">Larry K</b> <<a href="mailto:lunchtimelarry@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lunchtimelarry@gmail.com
</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Calling all LVM experts!!<br><br>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:
<br>
<ol style="font-style: italic;">
<li>Using fdisk, deleted /dev/hda4 partition
</li><li>Using fdisk, created /dev/hda4 as LVM
</li><li>Created physical volume: pvcreate /dev/hda4
</li><li>Extended volume group: vgextend vg /dev/hda4
</li><li>Ran vgdisplay to see amount of free space that needs to be extended (18214)
</li><li>unmount the volume group: umount /dev/vg/video
</li><li>extend: lvextend -l +18214 /dev/vg/video
</li><li>mount /dev/vg/video
</li><li>grow the xfs file system: xfs_grow /dev/vg/video
</li><li>Remove /video from /etc/fstab <br></li></ol>Now, df -k shows the new space: <br style="font-style: italic;"><br style="font-style: italic;">[root@mythtv ~]# df -k<br>Filesystem
1K-blocks Used Available Use% Mounted on <br>/dev/hda2
10080520 2938120 6630332 31% /<br>/dev/hda1
101086 16752
79115 18% /boot<br>none
257908
0 257908 0% /dev/shm<br style="font-style: italic;">
/dev/mapper/vg-video<span style="font-style: italic;"> 442105856 113816336 328289</span>520 26% /video2<br><br>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. <br><br>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<br><br>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. </blockquote>
<div> </div></span>
<div>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.
</div><span class="q">
<div> </div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">WTF?<br><br>There are no error messages in either the myth logs, nor the log file at /var/log/messages.
<br>
<br>I did notice that one of the HDs is running DMA 100, while the other is DMA 133. Does this matter to LVM? </blockquote>
<div> </div></span>
<div>Shouldn't make any difference.</div>
<div> </div>
<div> </div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><span class="q">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!
<br><span style="font-style: italic;"></span><br><br></span>_______________________________________________<br>mythtv-users mailing list<br><a href="mailto:mythtv-users@mythtv.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
</a><br><br><br></blockquote></div><br>
</blockquote></div><br>